DE19964013A1 - Verfahren und Vorrichtung zur Steuerung von Betriebsabläufen in einem Fahrzeug - Google Patents

Abstract

Verfahren und Vorrichtung zur Steuerung von Betriebsabläufen in einem Fahrzeug durch wenigstens eine Steuereinheit mit wenigstens einem nicht flüchtigen Speichermittel, wobei die Steuerung abhängig von der jeweiligen Ausführungsvariante des Fahrzeugs und/oder der Steuereinheit durchgeführt wird und bei einer Funktionsauswahl durch Vorgabe einer Kennung die jeweiligen Funktionen entsprechend der eingesetzten Ausführungsvariante ausgewählt werden, wobei den ausgewählten Funktionen wenigstens ein vorgebbarer Datensatz und/oder Programmcode im Speichermittel entspricht und der Datensatz und/oder Programmcode aus einer Mehrzahl von Datensätzen und/oder Programmcodes ausgewählt wird. Die Mehrzahl der Datensätze und/oder Programmcodes wird bei einer Variantenauswahl erstellt, wobei in der Kennung Konfigurationsparameter enthalten sind und die Konfigurationsparameter dazu dienen, den Datensatz und/oder den Programmcode zu bestimmen, wobei die jeweilige Kennung bzw. die Konfigurationsparameter bei der Variantenauswahl und bei der Funktionsauswahl eingesetzt werden.

Description

Stand der Technik

Die Erfindung betrifft ein Verfahren und eine Vorrichtung zur Steuerung von Betriebsabläufen in einem Fahrzeug durch wenigstens eine Steuereinheit mit wenigstens einem nicht flüchtigen Speichermittel, wobei die Steuerung abhängig von der jeweiligen Ausführungsvariante des Fahrzeugs und/oder der Steuereinheit durchgeführt wird gemäß den Oberbegriffen der unabhängigen Ansprüche.

Dazu zeigt die DE 38 02 241 A1 ein elektronisches Steuergerät für Kraftfahrzeuge, welches eine Zentraleinheit, einen Programmspeicher, einen Datenspeicher sowie eine Ein-/Ausgabe-Einheit mit mehreren Ein- und Ausgabekanälen umfaßt. Dabei ist die Grundausstattung gleichzeitig für mehrere unterschiedliche individuelle Ausführungsvarianten auslegbar. Dieser Grundausstattung ist ein Codespeicher für wenigstens ein Codewort zur Bestimmung der jeweiligen individuellen Ausführungsvariante zugeordnet. Zum Zeitpunkt des Einbaus in das Fahrzeug oder auch später wird das für die Fahrzeugausrüstungsvariante spezifische Codewort in den Codespeicher eingegeben, um damit die passende, spezielle Steuergeräteausführung anzusteuern bzw. freizugeben. Die zugehörigen Programmabschnitte, Datensätze, Ein- und/oder Ausgabekanäle sind in Abhängigkeit vom jeweiligen Inhalt des Codespeichers ansteuerbar. Dabei wird somit die, dem jeweiligen Fahrzeugtyp entsprechende Variante des Steuergeräts durch Eingabe des Codewortes und den Codespeicher bleibend festgelegt. Bei einer nachträglichen Änderung z. B. zusätzlichen Komponenteneinbau, kann wenn dies bereits vorgesehen war, durch ein neues Codewort diese neue Komponente berücksichtigt werden. Für den laufenden Betrieb des Fahrzeugs ist aber dann die entsprechende eine Variante festgelegt. Jeder Variante wird somit ein Codewort zugeordnet, wobei die festgelegten Varianten und deren Anzahl nicht mehr änderbar ist.

Gleiches gilt für die DE 35 43 966 A1. Hier wird ein Mehrrechnersystem mit wenigstens einem frei programmierbaren Speicher vorgeschlagen, der über einen Datenbus mit einem ersten Rechner in Verbindung steht. Die übrigen Rechner haben lediglich Zugriff auf fest programmierbare Speicher, in denen unterschiedliche Varianten von Datensätzen abgelegt sind. Über entsprechende Kennungen, die im frei programmierbaren Speicher abgelegt werden, können je nach Anwendung ein oder mehrere bestimmte Datensätze für die Programmbearbeitung ausgewählt werden. Auf diese Weise kann sehr einfach eine Anpassung an bestimmte Anwendungsgebiete erzielt werden, ohne daß hierfür jeweils spezielle Mehrrechnersysteme bereitgestellt werden müßten. Aber auch hier ist die Art der Varianten und die Zahl der Varianten entsprechend der bestimmten Datensätze festgelegt.

Es zeigt sich somit, daß der Stand der Technik nicht in jeder Hinsicht optimale Ergebnisse zu liefern vermag. Durch die Erfindung soll deshalb eine flexible, speicher- und laufzeitoptimale Umsetzung der Varianten bezüglich externer und interner Anforderungen realisiert werden.

Vorteile der Erfindung

Die Erfindung geht aus von Verfahren zur Steuerung von Betriebsabläufen in einem Fahrzeug durch wenigsten eine Steuereinheit mit wenigstens einem nicht flüchtigen Speichermittel, wobei die Steuerung abhängig von der jeweiligen Ausführungsvariante des Fahrzeugs und/oder der Steuereinheit durchgeführt wird und bei einer Funktionsauswahl durch Vorgabe einer Kennung die jeweiligen Funktionen entsprechend der eingesetzten Ausführungsvariante ausgewählt werden, wobei den ausgewählten Funktionen wenigstens ein vorgebbarer Datensatz und/oder Programmcode im Speichermittel entspricht. Der Datensatz und/oder Programmcode wird dabei aus einer Mehrzahl von Datensätzen und/oder Programmcodes ausgewählt.

Bei dem erfindungsgemäßen Verfahren wird vorteilhafterweise die Mehrzahl der Datensätze und/oder Programmcodes bei einer Variantenauswahl erstellt, wobei in der Kennung Konfigurationsparameter enthalten sind, welche dazu dienen, den Datensatz und/oder dem Programmcode zu ermitteln, wobei die jeweilige Kennung bzw. die Konfigurationsparameter bei der Variantenauswahl und bei der Funktionsauswahl eingesetzt werden.

Durch die Verwendung von gleichen Kennungen bzw. Schalterelementen bei der Softwarekonfiguration, der Applikation und der Funktionsauswahl am Bandende kann eine flexible, speicher- und laufzeitoptimale Umsetzung der Variantenbehandlung bezüglich verschiedenster Anforderungen erzielt werden. So kann auch nach Festlegung der Eigenschaften Einfluß auf die Auswahl der Varianten selbst, insbesondere der benötigten Applikationsdaten, genommen werden kann.

Dadurch können vorteilhafterweise unterschiedliche Fahrzeugmodelle, Austattungsvarianten von Fahrzeugen und Motorisierungen eines Fahrzeugsmodells mit unterschiedlichen Datensätzen aber einem Softwarecode bedient werden. Dadurch kann die Softwareentwicklung einen Programmcode entwickeln, pflegen und warten. Abgestimmt durch die Schalterelemente wird zweckmäßigerweise in der Applikation eine bestimmte Anzahl von Datensätzen erzeugt.

Weitere vorteilhafte Ausgestaltungen sind in der Beschreibung und den Merkmalen der Ansprüche offenbart.

Zeichnung

Die Erfindung wird im Weiteren anhand der in der Zeichnung dargestellten Figuren beschrieben.

Dabei zeigt Fig. 1 ein Steuergerät und mögliche Peripherie zur Steuerung von Betriebsabläufen in einem Fahrzeug.

Fig. 2 zeigt die Erstellung der jeweiligen Kennung (Schalterelemente) in einem Flußdiagramm.

Die Belegung der Kennung bzw. des Schalterelementes gemäß einer besonderen Ausführungsform ist in den Fig. 3a, 3b und 3c dargestellt.

Eine weitere Möglichkeit der Schalterelementbelegung bzw. Kennungsbelegung zeigen die Fig. 4a, 4b und 4c.

Beschreibung von Ausführungsbeispielen

In Fig. 1 ist ein Steuergerät 100 und dessen mögliche Peripherie schematisch dargestellt. Das Steuergerät beinhaltet eine serielle Ein-/Ausgangsbaugruppe 110 sowie eine parallele Ein-/Ausgangsbaugruppe 109. An die serielle Ein-/Ausgangsbaugruppe 110 sind seriell und bidirektional, dargestellt durch Verbindung 114, Peripherieelemente, dargestellt durch Peripherieelement 111, angeschlossen. Das Peripherieelement 111 symbolisiert dabei Peripherieelemente wie intelligente Sensorik oder Aktuatorik sowie integrierte Peripherieelemente mit Sensorik und Aktuatorik oder auch weitere über serielle Schnittstellen anschließbare Steuergeräte, insbesondere weitere Rechen- oder Steuereinheiten z. B. zur Applikation. Weitere Peripherieelemente, dargestellt durch Element 112, insbesondere Sensorik, ist unidirektional über Verbindung 115 mit dem Steuergerät 100 gekoppelt und liefert beispielsweise Meßwerte oder Meßergebnisse, insbesondere bereits vorverarbeitet bzw. aufbereitet an das Steuergerät. Ebenso werden Peripherieelemente, insbesondere Stellglieder, dargestellt durch Element 113 durch das Steuergerät über Ein-/Ausgangsbaugruppe 110 seriell angesteuert. Verbindung 116 symbolisiert dabei den undirektionalen Signalübergang.

So wie die serielle Anschlußseite besitzt das Steuergerät in diesem Beispiel wenigstens eine parallele Anschlußseite, symbolisiert durch Ein-/Ausgangsbaugruppe 109. Daran sind Peripherieelemente, dargestellt durch Element 117 parallel und bidirektional, symbolisiert durch Verbindung 120 angeschlossen. Dies kann einerseits ein Bussystem im Fahrzeug sein und damit sind parallel anschließbare Sensorik und Aktuatorik sowie weitere Steuergeräte und Steuereinheiten des Fahrzeugs anschließbar. Ebenso können weitere Peripherieelemente unidirektional und parallel, dargestellt durch Element 118 und Verbindung 121 an das Steuergerät angeschlossen sein, von welchen die Signale lediglich dem Steuergerät übermittelt werden. Gleichfalls ist Peripherie, insbesondere Aktuatorik, dargestellt durch Element 119 und Verbindung 122 denkbar, welche lediglich parallel und unidirektional durch das Steuergerät 100 bedient wird.

Die dargestellte Peripherie ist prinzipiell optional und je nach Steuergeräteausprägung bzw. unterschiedlichen Steuergeräten im Fahrzeug je nach Anwendung enthalten oder ausgespart.

Gleiches gilt für die weiteren Elemente im Steuergerät selbst, die je nach Steuergerät bzw. Steuerungsaufgabe im Fahrzeug variieren kann. Mit 101 ist dabei wenigstens ein Mikrocomputer enthalten, der seinerseits eine Prozessoreinheit 103 und einen internen Speicher 102, insbesondere einem Flashspeicher, oder eine interne Registerbank enthält. Im weiteren wird der interne Speicher als nichtflüchtiger Speicher, insbesondere als Flash-Speicher ausgeführt. Diese sind mit weiteren optionalen Bauelementen 105 im Mikrocomputer 101 durch das interne Leitungs- bzw. Bussystem 104 miteinander verbunden. Die zusätzlich und im einzelnen nicht dargestellten Elemente 105 sind beispielsweise weitere Speicherelemente, zusätzliche Prozessoreinheiten, insbesondere zur Prozeßzeitberechnung, Ein-/Ausgangsbaugruppen usw. Der Mikrocomputer 101 ist dabei über wenigstens ein steuergeräteinternes Leitungs-/Bussystem 107 mit weiteren Komponenten eben beispielsweise den Ein-/Ausgangsbaugruppen 109 und 110 verbunden. Mit 106 ist im allgemeinen ein weiteres Speichermittel insbesondere ein nichtflüchtiger Speicher wie z. B. ein EEPROM oder ein Flash-EPROM, EPROM, PROM oder ROM im Steuergerät 100 enthalten und mit dem Bussystem 100 verbunden. Im weiteren wird dabei von einem EEPROM ausgegangen, aber ein Flash-EPROM wäre ebenso denkbar. Weitere optionale und der Übersichtlichkeit halber nicht im einzelnen dargestellten Baugruppen sind durch Element 108 symbolisiert. Dabei handelt es sich beispielsweise um weitere Mikrocomputer, weitere Prozessoreinheiten, weitere Speichermittel, interne Sensorik beispielsweise zur Temperaturüberwachung, wenigstens eine Energieversorgung, usw.

Eine Anordnung wie in Fig. 1 bzw. vergleichbare Anordnungen werden zur Steuerung von Betriebsabläufen in einem Fahrzeug eingesetzt. Diese dienen insbesondere zur Steuerung einer Antriebseinheit, dem Antriebsstrang, insbesondere zur Getriebesteuerung, einer Bremsanlage oder zur Steuerung von Komfort- sowie Sicherheitssystemen. Im Zuge moderner X-By-Wire-Systeme werden diese auch bei der Lenkungs-, Bremsen-, Motor-, oder Fahrwerksregelung eingesetzt.

Die Steuergeräte Software läßt sich prinzipiell im Programmcode und Daten trennen. Aus Applikationsgründen werden die Daten ab einer definierten Adresse in sich geschlossen abgelegt. Der Inhalt des Datensatzes wird durch das Fahrzeug selbst, die angesteuerten Komponenten, insbesondere den Motor, und die Elemente die auf die Motorkenngrößen Einfluß haben bestimmt. Die Anzahl möglicher Ausstattungs-, Bestückungs- und sonstiger Varianten eines Fahrzeugs oder verschiedener Fahrzeuge, zusammenfaßbar als die Anzahl verschiedener Steuerungsvarianten bedingt inhaltlich unterschiedliche Datensätze, also Datensatzvarianten passend zu dem selben Programmcode bzw. den selben Teilen des Programmcodes.

Im weiteren wird das Speichermittel 102 im Mikrocomputer 101 nicht flüchtig, insbesondere als Flashspeicher angenommen. In diesem Speicher ist der wenigstens eine Datensatz zur Steuerung von Betriebsabläufen des Fahrzeugs abgelegt ebenso wie der Programmcode. Prinzipiell läßt sich die Software in Programmcode und Daten trennen. Unterschiedliche Varianten wie z. B. im Stand der Technik sind durch unterschiedliche Datensatzvarianten und unterschiedliche Programmteile repräsentiert. Die Mehrzahl dieser Programmcodes und Daten wird z. B. im Speicher 106 einem EEPROM abgelegt, woraus dann insbesondere am Bandende mit einem Codewort die benötigten Daten ausgewählt werden und zur Steuerung in Speicher 102 übertragen werden. Eine mögliche Realisierung ist z. B. die Verwendung eines Programmcodes, der alle Funktionen und Varianten enthält, wobei es mehrere in sich geschlossene Datensätze gibt. Daten und Code sind im Flash-EPROM 102 abgelegt. Im Steuergerätehochlauf, der Initialisierung wird ein Codewort, insbesondere ein oder mehrere Codebytes bzw. Codierbytes, aus dem EEPROM 106 gelesen, das den auszuwählenden Datensatz (1 aus X) auswählt (z. B. durch Manipulation der Adresse des Zeigers auf die Daten). Dabei besitzen die Datensätze alle die gleiche Struktur, damit sie zu Code passen. So werden die Fahrzeugvarianten insbesondere am Bandende realisiert. Über ein Eingabemedium, insbesondere einen Diagnosetester, wird der passende Datensatz als Kennung ins EEPROM 106 gespeichert. Denkbar ist auch eine Sektion im Flashspeicher 102 freizuhalten und diese erst später, insbesondere am Bandende, mit dem Codewort der auszuwählenden Datensatzvariante zu programmieren.

Ziel ist es nun, unterschiedliche Fahrzeugmodelle, Austattungsvarianten von Fahrzeugen und Motorisierungen eines Fahrzeugsmodells mit unterschiedlichen Datensätzen aber einem Softwarecode zu bedienen. Dadurch kann die Softwareentwicklung einen Programmcode entwickeln, pflegen und warten. Passend dazu wird durch die Applikation eine bestimmte Anzahl von Datensätzen erzeugt. Mit Kennungen bzw. Schaltelementen die als Datenkennzeichen im Datensatz abgelegt sind, im weiteren als Variantenschalter bezeichnet, können die Eigenschaften der jeweiligen Variante während der Softwaregenerierung bzw. Softwarekonfiguration, also einer bedingten Spezifikation der Software festgelegt werden.

Variantenschalter können bei der bedingten Spezifikation der Daten für den Datensatz und/oder in der Softwareabarbeitung des Programmcodes zum Durchlaufen unterschiedlicher Softwarepfade führen. Durch sie werden also die entsprechenden Funktionalitäten aktiviert und im Fall der bedingten Spezifikation die benötigten Applikationsdaten ausgewählt. Nach dem Programmstart, können die Variantenschalter in Nachrichten abgespeichert werden, wodurch der Zugriff auf die Variantenschalter im Programmcode durch Zugriffe auf den Datensatz zur Laufzeit des Programms erfolgt. Die ausschließliche Verwendung von Variantenschalter führt dazu, daß nach Festlegung der Eigenschaften kein Einfluß auf die Auswahl der Varianten selbst, insbesondere der benötigten Applikationsdaten, mehr genommen werden kann.

Die nachfolgende Auswahl, also von Funktionalität, die erst nachträglich, insbesondere am Bandende, festgelegt werden soll, beispielsweise ob das Fahrzeug eine Klimaanlage aufweist oder nicht und entsprechend gesteuert werden muß, kann über weitere Schaltelemente bzw. Kennungen, bezeichnet als Funktionsschalter gehandhabt werden. Diese Funktionsschalter führen in der Softwareabarbeitung des Programmcodes zum Durchlaufen unterschiedlicher Softwarepfade. Der Zugriff auf die Funktionsschalter zur Laufzeit des Programms erfolgt ebenfalls über Nachrichten, die in der Initialisierungsphase des Programms sowohl mit den zugehörigen Werten aus dem Datensatz, wie beispielsweise Variantenschalter, oder mit den zugehörigen Werten aus den Codierbytes aus einem nicht flüchtigen Speicher, insbesondere dem EEPROM, belegt werden können. Durch die Funktionsschalter kann somit nach bereits abgeschlossener Applikation die benötigte Funktionalität der jeweiligen Variante gewählt werden.

Erfindungsgemäß wird nun im Weiteren nicht mehr zwischen Variantenschalter und Funktionsschalter unterschieden. Durch das erfindungsgemäße Verfahren werden die Möglichkeiten beider Schalterelemente bzw. Kennungen durch eine einzige Kennung im weiteren allgemein als Softwareschalter bezeichnet realisiert. Diese Softwareschalter als Kennung, sind sowohl mit Werten aus dem Datensatz als auch mit Werten aus den Codierbytes des nicht flüchtigen Speichers, den EEPROM-Codierbytes, abhängig von Konfigurationsparametern belegbar. Dies wird erreicht, indem die Softwareschalterstruktur des jeweiligen Schalters einerseits in einer Konfigurationsdatei zur Softwaregenerierung und andererseits im Datensatz abgelegt wird. Damit entfällt der Aufwand der Änderung von Variantenschaltern in Funktionsschalter und umgekehrt.

In Fig. 2 ist ein Verfahren zur Definition bzw. Erstellung der Softwareschalter dargestellt. Block 200 stellt dabei den Start des Verfahrens dar, wenn Softwareschalter als Kennung verwendet werden. In den Blöcken 201 und 202 wird ein Softwareschalter SWS zunächst in der Konfigurationsdatei als Konstante für die Softwarekonfigurierung bzw. Softwaregenerierung definiert. Im Datensatz wird dazu eine Applikationsdatenstruktur angelegt, die der Softwareschalterstruktur bezüglich der Softwaregenerierung entspricht.

Dazu werden zunächst in Block 201 die Schalterstellungen des Softwareschalters als Systemkonstanten bezüglich der Softwaregenerierung angelegt. Zunächst werden also Schalterstellungen, die der Softwareschalter annehmen kann definiert. Die jeweils möglichen Schalterstellungen als Konstanten sind eindeutig einem Schalter als dessen Schalterstellungen zugeordnet. Der hier zu definierende Softwareschalter SWS1 kann so beispielsweise die konstanten Schalterstellungen 0, 1 und 2 annehmen. Bei der Steuergeräteinitialisierung wird anhand dieser Applikationswerte entschieden, ob der Schalterwert aus dem nichtflüchtigen Speicher 106, insbesondere dem EEPROM, oder aus dem Datensatz gelesen wird. Danach wird der gelesene Wert in eine Nachricht geschrieben, auf die im Programmcode zugegriffen wird.

Anschließend wird in Block 202 der Schalter selbst angelegt. Der Softwareschalter SWS1 selbst setzt sich aus zwei Konstanten bezüglich der Softwaregenerierung zusammen, durch welche einerseits der Wert KWERT des Softwareschalters festgelegt wird und einer zweiten Konstante KTYP die den Schaltertyp bezeichnet. Dem Schalterwert wird eine der vorher definierten Schalterstellungen zugewiesen. Für den Schaltertyp sind folgende Möglichkeiten vorgesehen:
Ein Schaltertyp A bedeutet, daß der Schalterwert aus dem Datensatz gelesen wird und eine nachträgliche konfigurative oder applikative Änderung des Schaltertyps nicht möglich ist. Dieser Schaltertyp wird für bedingte Spezifikation eingesetzt. Der Schalterwert kann in der Softwarekonfigurations- aber nicht mehr in der Applikationsphase verstellt werden.

Der Schaltertyp B bedeutet, daß der Schalterwert aus dem nicht flüchtigen Speicher 106, insbesondere dem EEPROM gelesen wird. Bei ungültigem Lesezugriff im EEPROM wird hierbei dann aber wieder der Datensatzwert verwendet.

Für einen Schaltertyp C wird als Schalterwert der Datensatzwert verwendet. Dieser Schaltertyp kann applikativ zu Schaltertyp B also einem Zugriff zum nicht flüchtigen Speicher 106 (EEPROM) verändert werden.

Dem Softwareschalter SWS1 wird somit einer dieser Typen KTYP A, B oder C zugewiesen, wodurch angegeben ist, aus welchem Speicherbereich die Daten gelesen werden sollen. Die entsprechende Schalterstellung wird in Block 202 vorgegeben. Dabei wird eine der vorher definierten Schalterstellungen 0, 1, 2 dem Schalterwert KWERT zugewiesen. Schaltertyp und Schalterwert bzw. deren Inhalte (hier A, B, C und 0, 1, 2) bestimmen somit ebenfalls quasi als Konfigurationsparameter den Datensatz (die Datensätze) bzw.. den Programmcode (die Programmcodes).

Analog zu der Softwareschalterdefinition bezüglich der Softwarekonfigurierung bzw. Softwaregenerierung muß die Softwareschalterstruktur im Datensatz abgelegt werden. Dazu wird in der Konfigurationsdatei der entsprechenden Funktion einer Komponente die Schalterstruktur für SWS 1 angelegt. Diesem Datensatzschalter wird über einen Konfigurationsparameter der entsprechende Softwareschalter bezüglich der Softwaregenerierung zugewiesen. Die Belegung des zugehörigen Schaltertyps im Datensatz erfolgt analog, wobei ebenfalls ein Konfigurationsparameter auf den dazugehörigen Schaltertyp der Softwaregenerierung gesetzt wird.

Nachdem in Block 202 die Schalterstellung vorgegeben wurde, wird nun in Abfrage 203 überprüft, ob der Softwareschalter der bedingten Spezifikation dient oder nicht. Ist dies der Fall, also der Schaltertyp A gelangt man zu Block 205 der bedingten Spezifikation. Dabei werden in Block 205 die bedingt zu spezifizierenden Daten mit einer Kennzeichnung in den Gesamtdaten umklammert. Die bedingte Spezifikation ist besonders vorteilhaft in den Fällen, in denen die Varianten von Softwaremodulen die gleiche Datenstruktur besitzen, die Umsetzung der physikalischen Werte in rechnerinterne jedoch unterschiedlich ist. Dies ist dann der Fall, wenn dieselbe Ausgangsgröße in den einzelnen Varianten von unterschiedlichen Eingangsgrößen abhängig ist. Wird beispielsweise ein Größe wahlweise aus zwei Ausgangsgrößen beispielsweise über eine Kennlinie oder ein Kennfeld ermittelt, müssen die Kennlinien obwohl möglicherweise gleich, unterschiedlich definiert werden. Die Auswahl der gewünschten Kennlinie erfolgt im Programmcode durch eine Applikationsgröße. Demnach müßten beide Kennlinien im Datensatz enthalten sein. Wird nun die Kennlinie bedingt spezifiziert, sind nun im Konfigurationsteil beide Kennlinien mit dem selben Namen spezifiziert. Die Auswahl der benötigten Kennlinie erfolgt während der Softwarekonfiguration bzw. Softwaregenerierung in Abhängigkeit des Softwareschalters SWS. Damit ist nur die benötigte Kennlinie im Datensatz und damit im Speicher des Steuergeräts enthalten. Dabei ist wesentlich, daß die bedingt zu spezifizierenden Daten zwischen eindeutigen Identifikationszeichen in den Daten abgelegt sind, wodurch bei der Softwaregenerierung in Abhängigkeit der Stellung des Softwareschalters eben nur diese durch die Identifizierung/Kennzeichnung umgebenen Daten spezifiziert werden.

Wird anhand des Schalterwertes, der die aktuelle Schalterstellung widerspiegelt festgestellt, daß der Schalter nicht der bedingen Spezifikation dient sondern Funktionalitäten für Varianten aktivieren soll, gelangt man zu Abfrage 204. Darin wird abgefragt, ob die Funktionalität, vergleichbar dem eingangs genannten Funktionsschalter, nach abgeschlossener Applikation aktiviert werden soll oder nicht.

Soll die Funktionalität der Variante erst nach abgeschlossener Applikation aktiviert werden, gelangt man zu Block 206. Darin ist nun über die Typdefinition festgelegt, daß die Daten aus dem nicht flüchtigen Speicher, insbesondere dem EEPROM gelesen werden.

Soll die Funktionalität bereits bei der Applikation festgelegt werden, gelangt man zu Block 207. Darin ist nun vorgegeben, daß als Schalterwert der Datensatzwert verwendet wird. Somit wird zwar hier auch wie bei der bedingten Spezifikation aus dem Datensatz gelesen, dieser Schaltertyp kann aber applikativ so verändert werden, daß ein Zugriff auf den nicht flüchtigen Speicher insbesondere das EEPROM möglich wird.

Im Anschluß gelangt man aus Block 205, 206 und 207 zu Block 208. In Block 208 wird nun das Softwareschalterkonstrukt in der Konfigurationsdatei angelegt. Daraufhin wird im Block 209 eine Enumeratoridentifikation EID in einem vorgebbaren Datenbereich angelegt, wobei die EID softwareschalter­ spezifisch ist. Über sie wird bei einem Zugriff auf den nicht flüchtigen Speicher 106 die Position des Schalters relativ zum Anfang des Schalterbereichs im nicht flüchtigen Speicher 106 bestimmt. Da bei Zugriff auf den nicht flüchtigen Speicher 106 zwei Softwareschaltertypen B und C in Frage kommen, kann damit der Softwareschalter SWS referenziert werden.

In Block 210 wird schließlich die Stellung des Softwareschalters abgefragt und die Schalterstellung in einer Nachricht bereitgestellt, auf welche im Programmlauf zugegriffen werden kann. Die Stellung des SWS wird in der Prozeßinitialisierung der zugehörigen Komponente des Fahrzeugs abgefragt. Die erhaltene Schalterstellung wird in einer Nachricht abgelegt, auf die die Komponente zugreifen kann. Um auf den Schaltertyp direkt im Programmcode zugreifen zu können muß der Schaltertyp in der zugehörigen Konfigurationsdatei referenziert werden.

Eine Neubelegung der Softwareschalter wird zweckmäßigerweise nach dem Abschalten durchgeführt. Nach dem Einschalten also dem Hochfahren bzw. Initialisieren der Steuergeräte steht dann die neue Konfiguration zur Verfügung. Die Belegung des Softwareschalters SWS könnte aber auch im laufenden Fahrzyklus insbesondere über ein Eingabemedium erfolgen (z. B. mittels Diagnosetester). Aus Zeitgründen werden die Werte in der Initialisierung, also nach Zündung AUS → EIN, in die SWS-Nachricht gespeichert, da bei verschiedenen Übertragungsmedien, insbesondere Bussystemen wie dem I2C-BUS, die Übertragungszeit für ein Laden aus dem EEPROM (106) zu lange dauern würde. Bei Verwendung schnellerer Übertragungsmedien (leitungsgebunden, leitungslos) beispielsweise einem schnelleren Bussystem, kann der SWS dann auch im Fahrzyklus neu belegt werden, wodurch ein flexibles Umapplizieren z. B. bei Auftreten eines Fehlers möglich wäre. Ist ein Umapplizieren des Steuergerätes im Fahrbetrieb unerwünscht kann diese Funktion im Fahrzyklus gesperrt werden.

In Block 211 schließlich ist das Ende der Softwareschaltererstellung erreicht und es wird die Programmstruktur in Abhängigkeit der Softwareschalternachricht durchlaufen.

In den Fig. 3a, 3b und 3c ist nun eine weitere Möglichkeit der Schalterbelegung gemäß einer vorteilhaften Ausführungsform beschrieben. Die ursprünglichen Datenkennungen für den Schalter im Datensatz im weiteren als Label 1, L1 bezeichnet, werden jeweils um eine weitere Kennung Label 2, L2 erweitert. Nach dem Löschen des nicht flüchtigen Speichers 102 bekommen die Label 2 L2 z. B. den Löschwert des Speichers, der nach abgeschlossener Applikation, insbesondere am Bandende, programmiert werden kann. Dies gilt für eine Byte- bzw. Wortweise Programmierung des nicht flüchtigen Speichers. Wird das Label 2, L2 z. B. mit der Invertierung des Löschwertes belegt, so kann eine Einstellung für den zugehörigen Schalter am Bandende verboten werden und die Schalternachricht wird mit dem vorher eingestellten Wert des Label 1 L1 gefüllt. Die beiden Label L1 und L2 sind dazu in Fig. 3b als Block 301 dargestellt. Der Schalter ist in Fig. 3a als Block 300 dargestellt. Dabei ist mit C eine Codierkennung angegeben, durch welche entschieden wird, welche Werte in die Schalternachricht, die Schalterdaten SD zu füllen sind. Steht die Codierkennung C, insbesondere ein Bit, im nicht flüchtigen Speicher 106, EEPROM auf codiert und stimmt die Sicherheitsüberprüfung S. insbesondere eine Checksumme, über alle Schalterdaten SD im nicht flüchtigen Speicher so werden die Schalterwerte aus dem nicht flüchtigen Speicher, EEPROM in die Schalternachricht gefüllt, ansonsten, die Schalterwerte aus dem Datensatz 301. Das Schreiben von den Codierbytes bzw. Schalterdaten SD ins EEPROM kann mittels Applikationsgerät am Bandende erfolgen.

Das Verfahren ist in Fig. 3c nochmals dargestellt. Der Start des Verfahrens erfolgt in Block 302. In Abfrage 303 wird überprüft, ob Label 2, L2 dem Löschwert entspricht. Ist dies der Fall, gelangt man zu Abfrage 305. Darin wird abgefragt, ob der nicht flüchtige Speicher insbesondere das EEPROM codiert ist oder nicht. Ist dies der Fall, gelangt man zu Abfrage 306 wo die Sicherheitskennung S, insbesondere die Checksumme, überprüft wird. Ist die Checksumme S in Ordnung, wird der Schalter mit den Daten aus dem nicht flüchtigem Speicher, dem EEPROM belegt. Ist die Checksumme nicht in Ordnung wird der Schalter in Block 308 mit dem Ursprungslabel L1 belegt. Ist das EEPROM in Abfrage 305 nicht codiert bzw. die Codierkennung C auf nicht codiert gestellt, wird ebenfalls in Block 308 der Schalter mit L1 belegt. Ist in Abfrage 303 Label L2 nicht mit dem Löschwert belegt, gelangt man zu Abfrage 304. Darin wird abgefragt, ob Label L2 mit dem inversen Löschwert, also einem einfach zu erkennenden Wert belegt ist. Ist dies der Fall, wir d wiederum das Basislabel L1 in Block 308 in den Schalter gelegt. Ist in Label L2 weder der Löschwert noch der inverse Löschwert programmiert, wird in den Schalter der Inhalt des Zusatzlabels L2 eingebracht. In Block 310 wird dann die Software entsprechend der Schalterbelegung aus Block 309, 308 bzw. 307 durchlaufen.

Fig. 4a, 4b und 4c zeigt die Möglichkeit der Schalterbelegung wenn eine byte- oder wortweise Programmierung beispielsweise durch die Flashspeichertechnologie nicht möglich ist. Dann kann es nötig sein, das Zusatzlabel L2 in einer Sektion, also der kleinsten zu programmierenden Einheit des Speichers abzulegen. Die Datenlabel für die Schalter im Datensatz also L1 werden diesmal um ein weiteres Label ein Freigabelabel L3 erweitert. Ist der Wert des Freigabelabels L3 mit einem Gültigwert gefüllt, kann die Schalterbelegung auch nach abgeschlossener Applikation also insbesondere am Bandende durch Umprogrammieren des Labels L2 oder der jeweiligen Bits der Schalterdaten SD eingestellt werden. Fig. 4a zeigt dazu wieder einen Schalter, dessen Umfang mit 400 gezeichnet ist, eine Codierkennung C, die Schalterdaten SD und die Sicherheitsdaten, insbesondere eine Checksumme, S. Die drei genannten Label L1, L2 und L3 sind in 401 in Fig. 4b dargestellt.

In diesem Fall lassen sich die Schalternachrichten auch einsparen, wenn die Werte aus den Schalterdaten SD, dem Codierbyte bzw. die Ursprungslabel L1 und die Zusatzlabel L2 immer in den gleichen Speicher (z. B. Flash-EPROM 102) der Zusatzlabel L2 programmiert werden und durch die Software diese Zusatzlabel also der Speicherplatz der Label L2 abgefragt wird.

Dieses Verfahren ist nun in Fig. 4c noch einmal dargestellt. Block 402 zeigt wieder den Start des Verfahrens und Abfrage 403 die Auswertung des Freigabelabels L3. Ist das Freigabelabel gültig, also mit einem Gültigwert belegt, gelangt man zu Abfrage 404, in welcher überprüft wird, ob Label L2 mit dem Löschwert belegt ist. Ist dies nicht der Fall, gelangt man zu Block 409, wo der Schalter mit dem Label L2 belegt wird. Ist der Freigabelabel in Abfrage 403 nicht gültig, gelangt man zu Block 407, in welchem der Schalter mit dem Ursprungslabel L1 belegt wird. Entspricht in Abfrage 404 der Label L2 dem Löschwert des nicht flüchtigen Speichers gelangt man zu Abfrage 405 wo wiederum wie vorher 3c überprüft wird, ob die Codierkennung C gesetzt ist oder nicht. Ist sie gesetzt, der nicht flüchtige Speicher also codiert, gelangt man zu Abfrage 406. Darin erfolgt die Checksummenprüfung also der Sicherheitsinformation S. Ist die Überprüfung positiv, insbesondere die Checksumme O.K. wird der Schalter mit den EEPROM-Bits belegt. Ist die Summe nicht O.K. gelangt man wiederum zu Block 407. Ebenso zu Block 407 der Belegung des Schalters mit dem Ursprungslabel L1 gelangt man, wenn die Codierkennung C nicht codiert anzeigt. In Block 410 wird dann das Programm abhängig von der Schalterbelegung durchlaufen.

Claims (12)

1. Verfahren zur Steuerung von Betriebsabläufen in einem Fahrzeug durch wenigstens eine Steuereinheit mit wenigstens einem nicht flüchtigen Speichermittel, wobei die Steuerung abhängig von der jeweiligen Ausführungsvariante des Fahrzeugs und/oder der Steuereinheit durchgeführt wird und bei einer Funktionsauswahl durch Vorgabe einer Kennung die jeweiligen Funktionen entsprechend der eingesetzten Ausführungsvariante ausgewählt werden, wobei den ausgewählten Funktionen wenigstens ein vorgebbarer Datensatz und/oder Programmcode im Speichermittel entspricht und der Datensatz und/oder Programmcode aus einer Mehrzahl von Datensätzen und/oder Programmcodes ausgewählt wird, dadurch gekennzeichnet, daß die Mehrzahl der Datensätze und/oder Programmcodes bei einer Variantenauswahl erstellt wird und in der Kennung Konfigurationsparameter enthalten sind und die Konfigurationsparameter dazu dienen, den Datensatz und/oder den Programmcode zu bestimmen, wobei die jeweilige Kennung bzw. die Konfigurationsparameter bei der Variantenauswahl und bei der Funktionsauswahl eingesetzt werden.

2. Verfahren nach Anspruch 1, dadurch gekennzeichnet, daß eine Struktur der jeweiligen Kennung einerseits in einer Konfigurationsdatei zur Softwaregenerierung und andererseits im Datensatz abgelegt wird.

3. Verfahren nach Anspruch 1, dadurch gekennzeichnet, daß die Kennung als Konfigurationsparameter einen ersten Parameter (KTYP) enthält, der angibt, aus welchem Speicher und/oder Speicherbereich ein Wert als zweiter Parameter (KWERT) gelesen werden soll, welcher seinerseits als Konfigurationsparameter den auszuwählenden Datensatz und/oder Programmcode angibt.

4. Verfahren nach Anspruch 3, dadurch gekennzeichnet, daß der erste Parameter so vorgebbar ist, daß der Wert aus dem Datensatz gelesen wird und eine nachträgliche Änderung des ersten Parameters verhindert wird, wobei der Datensatz in dem nicht flüchtigen Speichermittel (102) abgelegt ist.

5. Verfahren nach Anspruch 4, dadurch gekennzeichnet, daß der erste Parameter bei einer bedingten Spezifikation eingesetzt wird, wobei bedingt zu spezifizierende Daten zwischen eindeutigen Identifikationszeichen im Datensatz abgelegt sind.

6. Verfahren nach Anspruch 3, dadurch gekennzeichnet, daß der erste Parameter so vorgebbar ist, daß der Wert aus einem weiteren nicht flüchtigen Speicher (106) gelesen wird, wobei bei ungültigem Lesezugriff im weiteren nichtflüchtigen Speicher (106) der Wert aus dem Datensatz gelesen wird.

7. Verfahren nach Anspruch 3, dadurch gekennzeichnet, daß der erste Parameter so vorgebbar ist, daß der Wert aus dem Datensatz gelesen wird und der erste Parameter derart verändert werden kann, daß der Wert aus dem weiteren nicht flüchtigen Speicher (106) gelesen wird.

8. Verfahren nach Anspruch 1, dadurch gekennzeichnet, daß die Kennung mit verschiedenen Kennungsvarianten belegt werden kann, wobei als Kennungsvarianten im Datensatz eine erste und zweite Kennung enthalten ist und im weiteren nicht flüchtigen Speicher (106) eine dritte Kennung enthalten ist, wobei die erste Kennung vorgegeben wird und die zweite Kennung vorgebbar ist, wobei abhängig vom Wert der zweiten Kennung die Kennungsvariante ausgewählt wird, mit der die Kennung belegt wird.

9. Verfahren nach Anspruch 8, dadurch gekennzeichnet, daß eine vierte Kennung im Datensatz enthalten und vorgebbar ist und abhängig von der vierten und der zweiten Kennung die Kennungsvariante aus der ersten, zweiten und dritten Kennung ausgewählt wird, mit der die Kennung belegt wird.

10. Verfahren nach Anspruch 1 und 8 oder 9, dadurch gekennzeichnet, daß in der Kennung eine Codierkennung (C) enthalten ist, welche anzeigt, ob in dem weiteren nicht flüchtigen Speicher (106) eine dritte Kennung abgelegt ist oder nicht und daß auch abhängig von der Codierkennung (C) die Kennungsvariante ausgewählt wird, mit der die Kennung belegt wird.

11. Verfahren nach Anspruch 1 und 8 oder 9, dadurch ge­ kennzeichnet, daß in der Kennung eine Sicherheitskennung (S) enthalten ist, welche anzeigt, ob die dritte Kennung im nicht flüchtigen Speicher korrekt ist und daß auch ab­ hängig von der Sicherheitskennung (S) die Kennungsvarian­ te ausgewählt wird, mit der die Kennung belegt wird.

12. Steuereinheit zur Steuerung von Betriebsabläufen in einem Fahrzeug mit wenigstens einem nicht flüchtigen Speichermittel, wobei die Steuerung gemäß wenigstens eines Datensatzes und/oder Programmcodes durchgeführt wird, dadurch gekennzeichnet, daß der wenigstens eine Datensatz und/oder Programmcode nach einem Verfahren gemäß einem der Ansprüche 1 bis 11 bereitgestellt und/oder verwendet wird.