DE19963210A1

DE19963210A1 - Verfahren und Vorrichtung zur Steuerung eines Fahrzeugs

Info

Publication number: DE19963210A1
Application number: DE1999163210
Authority: DE
Inventors: Juergen Bauer; Volker Pitzal; Udo Schulz
Original assignee: Robert Bosch GmbH
Current assignee: Robert Bosch GmbH
Priority date: 1999-12-28
Filing date: 1999-12-28
Publication date: 2001-07-12
Also published as: JP2001239901A

Abstract

Verfahren und Vorrichtung in Form eines elektronischen Systems zur Steuerung eines Fahrzeugs, welches anhand einer Daten- und/oder Programmstruktur dargestellt wird, wobei die Daten- und/oder Programmstruktur Fahrzeugkomponenten, Koordinationskomponenten und Funktionskomponenten sowie Komponentenschnittstellen umfaßt, wobei die Komponenten einander zugeordnet sind und jede Komponente wenigstens eine Basisvariante und Funktionsvarianten besitzt. Jeder Komponente wird eine erste Kennung eindeutig zugeordnet. Der Basisvariante und der jeweiligen Funktionsvariante wird eine zweite Kennung zugeordnet. Des weiteren wird ein Kennungsblock für jede Komponente, der die erste Kennung der jeweiligen Komponente, die zweite sowie die erste Kennung einer zugeordneten Komponente umfaßt, gebildet und zur Fahrzeugsteuerung eingesetzt.

Description

Stand der Technik

Die Erfindung betrifft Verfahren zur Steuerung eines Fahr zeugs und eine Vorrichtung in Form eines elektronischen Sy stems für ein Fahrzeug gemäß den Oberbegriffen der unabhän gigen Ansprüche.

Die DE 41 11 023 A1 (US 5,351,776) zeigt dazu ein elektroni sches System für ein Fahrzeug, welches aus Elementen zur Durchführung von Steueraufgaben wenigstens, bezüglich der Mo torleistung, der Antriebsleistung und des Bremsvorgangs und aus Elementen, die das Zusammenwirken der Elemente zur Durchführung von Steueraufgaben koordinieren im Sinne einer Steuerung des Betriebsverhaltens des Fahrzeugs entsprechend dem Fahrerwunsch, besteht. Die Elemente sind dabei in Form einer Hierarchie angeordnet, wobei das wenigstens eine Koor dinationselement einer Hierarchieebene bei der Umsetzung des Fahrerwunsches in ein entsprechendes Betriebsverhalten auf die Elemente der nächsten Hierarchieebene und damit auf ein vorgegebenes Untersystem des Fahrer-Fahrzeug-Systems unter Bereitstellung des jeweils von der höheren Hierarchieebene für dieses Untersystem geforderten Verhaltens eingreift.

Desweiteren zeigt die DE 197 09 317 A1 ein Verfahren und ei ne Vorrichtung zur Steuerung eines Fahrzeugs, welches wenig stens eine Quelle für wenigstens eine Ressource und wenig stens einen Verbraucher umfaßt, der diese Ressource ver braucht. Dabei ist wenigstens ein Koordinator vorgesehen, der abhängig vom Potential der Quelle und vom Ressourcenbe darf des Verbrauchers die Ressource dem Verbraucher zuteilt.

Die im Stand der Technik enthaltenen Daten- und/oder Pro grammstrukturen sind in ihrer Gänze anhand der Steuergeräte- Software nicht darstellbar. Die Steuergeräte-Software läßt sich üblicherweise in Programm und Daten gliedern. Einem Programm ist meist eine Datensatzvariante aus einer Auswahl von Datensätzen zugeordnet. Beide Teile, also Programm und Daten sind im Steuergeräte-Programm bzw. einem Datenspeicher abgelegt. Zur Kennzeichnung und Verifizierung der Programm- und Datenstände sind beispielsweise im hexadezimalen File Kennungen abgelegt. Im Stand der Technik sind dies üblicher weise eine Software-Programm-Kennung, welche das Kurzzeichen für das Projekt und die Programmversion enthält, sowie eine Datensatzkennung, welche das Kurzzeichen für Projekt- und Datensatzvariante enthält. Somit läßt sich im Stand der Technik die Funktionalität einer im Steuergerät befindlichen Software anhand der genannten Kennungen sowie der Ge samtfunktionalität der Programmversion, welche aus der Soft ware-Funktions-Dokumentation ersichtlich ist, ableiten.

Da dabei kein Single-source-Prinzip gegeben ist, d. h. Pro gramm und Dokumentation getrennt zu verschiedenen Zeitpunk ten aus verschiedenen Quellen gespeist werden, ohne solche, insbesondere Änderungs-Informationen zusammenzuführen, ist eine Kompatibilitätsprüfung sehr aufwendig. Die Daten und/oder Programmstruktur des Standes der Technik und deren Anzeigemöglichkeit entspricht dem Inhaltsverzeichnis einer Funktionsdokumentation. Sie gibt nicht die funktionalen In halte der Komponenten, beispielsweise bezüglich der einge setzten Variante, wieder.

So zeigt sich, daß der Stand der Technik nicht in jeder Hin sicht optimale Ergebnisse zu liefern vermag. Deshalb soll eine verbesserte Software-Konfigurations- bzw. Software- Architektur-Kennung in einem Steuergerät zur Steuerung eines Fahrzeugs realisiert werden.

Vorteile der Erfindung

Die Erfindung geht aus von einem Verfahren zur Steuerung ei nes Fahrzeugs, welches in einer Daten- und/oder Programm struktur dargestellt wird, wobei die Daten- und/oder Pro grammstruktur Fahrzeugkomponenten, Koordinationskomponenten und Funktionskomponenten sowie Komponentenschnittstellen um faßt, wobei die Komponenten einander zugeordnet sind und je de Komponente eine Basisvariante und Funktionsvarianten be sitzt.

Ebenso geht die Erfindung von einem elektronischen System für ein Fahrzeug, bestehend aus Fahrzeugkomponenten, Koordi nationskomponenten und Funktionskomponenten aus, wobei die Komponenten einander zugeordnet sind und jede Komponente ei ne Basisvariante und Funktionsvarianten besitzt und die Kom ponenten über Komponentenschnittstellen Nachrichten austau schen.

Erfindungsgemäß wird nun jeder Komponente eine erste indivi duelle Kennung zugeordnet, wobei der Basisvariante sowie der jeweiligen Funktionsvariante eine zweite Kennung zugeordnet ist und vorteilhafter Weise ein Kennungsblock für jede Kom ponente, der eine erste Kennung der jeweiligen Komponente und deren zweite Kennung sowie die erste Kennung einer zuge ordneten Komponente umfaßt, zur Steuerung des Fahrzeugs ein gesetzt wird.

Zweckmäßigerweise ist die Quellcode- und Dateiablagestruktur deckungsgleich mit der zugrunde gelegten Daten- und/oder Programmstruktur. Das bedeutet, daß alle Prozesse einer Kom ponente bzw. die dazugehörigen Softwarefiles die Namen bzw. die Kennung der Komponente der zugrunde gelegten Daten- und/oder Programmstruktur (Architektur) haben. Somit erhält jede Komponente der Architektur eine eindeutige Kennung. Diese Kennung und die Kennung der übergeordneten Komponente bzw. zugeordneten Komponente und eine Kennung für die Basis- und Funktionsvariante geben die Stellung der Komponente in nerhalb der Architektur und deren funktionalen Inhalt ein deutig wieder.

Vorteilhafter Weise wird dieser Kennungsblock für jede Kom ponente durch eine Hilfskomponente generiert. Diese Hilfs komponente ist beispielsweise in den Makelauf eingebunden und speichert alle Kennungsblöcke an einer definierten Adresse, insbesondere im hexadezimalen File ab. Dadurch läßt sich vorteilhafter Weise jederzeit eine im Feld befindliche Software schnell identifizieren.

In einer weiteren Ausgestaltung könnte die gleiche Hilfskom ponente oder eine weitere Hilfskomponente die Kennung vor teilhafter Weise auslesen und insbesondere grafisch die Ar chitektur, also die Daten- und/oder Programmstruktur anzei gen. In einer weiteren vorteilhaften Ausgestaltung ist denk bar, daß die Architektur mit ihren funktionalen Varianten vorgegeben wird. Im Makelauf kann dann immer zweckmäßiger weise die Sollarchitektur mit der Istarchitektur verglichen und damit überprüft werden. Damit läßt sich zweckmäßigerwei se verhindern, daß bei einer großen Projektanzahl und Viel falt die Architektur im Laufe der Entwicklungszeit zerfällt.

Obwohl die Architektur nicht zwingend hierarchisch ist, kön nen grundlegende Beziehungen bzw. grundlegende Zuordnungen über Verfahren zur Konsistenzhaltung vorteilhafter Weise ge sichert werden. Dies kann zweckmäßigerweise durch Textsum menbildung der Kennungsblöcke dieser Grundbeziehungen oder durch Vergleichsroutinen erfolgen.

Durch die somit beschriebene in eine Kennung integrierte Funktions- bzw. Positionsbeschreibung der Einzelkomponenten kann die Funktionsdokumentation integriert werden. Jede Änderung ist zweckmäßigerweise im Datensatz bzw. Programmstand bei nachfolgender Bearbeitung vorhanden und nachvollziehbar durch die Einführung eines Single-documentation-Prinzips, was weiterhin verschiedene Änderungsquellen ermöglicht. Da mit kann allgemein eine Softwarestruktur bzw. Architektur in einem Steuergerät aufgezeigt werden.

Weitere Vorteile und vorteilhafte Ausgestaltungen ergeben sich aus der Beschreibung und den Merkmalen der Ansprüche.

Zeichnung

Die Erfindung ist nachfolgend anhand der in der Zeichnung dargestellten Figuren gezeigt.

Fig. 1 zeigt ein Blockschaltbild einer möglichen Konfi guration eines Steuersystems eines Fahr zeugs mit einem Leitungs- bzw. Bussystem.

Fig. 2 zeigt allgemein eine Softwarestruktur bzw. Ar chitektur (Daten- und/oder Programmstruk tur für ein Fahrzeug).

Beschreibung der Ausführungsbeispiele

In Fig. 1 ist ein Übersichtsblockschaltbild eines möglichen Steuersystems eines Fahrzeugs dargestellt. Dabei ist mit 100 eine Steuereinheit zur Steuerung des Motors bzw. der An triebseinheit gezeigt. In dieser Steuereinheit hardwaremäßig enthalten sind mit 101 die Steuerung des Luftsystems (u. a. Luftzumessung), mit 102 die Steuerung des Einspritzsystems (u. a. Kraftstoffzumessung), die optional auch eine Zündungs einstellung 102o z. B. für Benzin-Brennkraftmaschinen oder ein Glühsystem bei Diesel-Brennkraftmaschinen enthält. Des weiteren ist eine Steuerung der Antriebs- bzw. Motormechanik 103 z. B. zur Berechnung des Motorschleppmoments, zum Schutz vor mechanischer Überlastung, Bestimmung der Motordrehzahlen und des Kurbelwellenwinkels usw. vorgesehen. Daneben ist ei ne Steuereinheit 105 zur Steuerung der Bremsen bzw. des Bremsvorgangs, eine Steuereinheit 104 zur Steuerung eines automatischen Getriebes und/oder mit 106 eine Steuereinheit zur Steuerung der Fahrwerkseinstellung bzw. zur Fahrdyna mikregelung gezeigt, wobei in der Steuereinheit 106 optional mit 106o eine Lenkungssteuerung bei möglichem Eingriff in das Lenksystem (steer by wire) vorgesehen ist.

Darüber hinaus kann bei einem elektronisch geregelten Bord netz mit Steuereinheit 116 eine Einheit zur Steuerung des Bordnetzes eingesetzt werden. In diese integriert können Steuereinheiten zur Steuerung einzelner oder mehrere Nebe naggregate bzw. Anzeigeelemente sein. Beispielhaft ist hier mit 116o optional eine Steuereinheit für die Klimaanlage in die Steuereinheit 116 des Bordnetzes integriert. Ein Lei tungssystem bzw. Bussystem 111 (z. B. ein CAN-Bus) verbindet die einzelnen Steuereinheiten bzw. Steuergeräte zum gegen seitigen Informations- und Datenaustausch.

An dieses Leitungssystem bzw. Bussystem 111 sind über ent sprechende Leitungen 114, 115, welche beispielhaft für eine beliebige Anzahl ausgeführt sind, verschiedene Meßeinrich tungen 109, 110 angebunden. Wobei auch hier beispielhaft zwei einer beliebigen Anzahl herausgestellt sind. Diese Meßeinrichtungen 109, 110 usw. erfassen -Betriebsgrößen des Fahrzeugs, insbesondere von Motor und Antriebsstrang. Die erfaßten Betriebsgrößen stellen dabei im allgemeinen bekann te Betriebsgrößen wie beispielsweise die Motordrehzahl, die Motortemperatur, Abtriebsdrehzahl, Getriebestellung bzw. Übersetzung, Ganginformation, Wandlerschlupf, Turbinendreh zahl, Generatordrehzahl, Fahrgeschwindigkeit, Batteriespan nung, usw. dar. Daneben sind an das Bussystem 111 über ent sprechende Leitungen 112, 113 Stelleinrichtungen 107, 108 angeschlossen. Auch hierbei sind beispielhaft lediglich zwei Stelleinrichtungen dargestellt, welche eine Vielzahl mögli cher Steller im Fahrzeug repräsentieren. Dies sind bei spielsweise Zündungssysteme, elektrisch steuerbare Drossel klappen, Kraftstoffeinspritzsysteme, Steller eines Automa tikgetriebes wie z. B. Kupplungen oder Fahrwerkssteller, wie elektrisch steuerbare Federdämpferelemente, Drucksysteme zur Bremsbetätigung, die Servopumpe im Lenkungsbereich sowie Stellmotoren, z. B. für elektrische Fensterheber oder Schie bedach der Karosserie und Innenraumelektronik. Über entspre chende Leitungen 119, 120 sind wieder repräsentativ mit 117 und 118 zwei Anzeigeelemente einer beliebigen Anzahl darge stellt, die sich beispielsweise ebenfalls in der Karosserie- und Innenraumelektronik finden. Diese z. B. optischen oder akustischen Anzeigeelemente sind hierbei separat zu den Stellelementen 107, 108 dargestellt.

Die in Fig. 1 dargestellten Steuereinheiten führen die ih nen zugeordneten Funktionen und der Erfassung der dazu not wendigen Betriebsgrößen durch und bilden Steuerwerte für die verschiedenen Stelleinrichtungen und Anzeigeelemente. Durch einen solchen dargestellten Systemverbund können einzelne Elemente oder Funktionseinheiten nicht mehr getrennt be trachtet werden, sondern eingebunden in das Gesamtkonzept. Dadurch ergibt sich aber auch die Möglichkeit, durch den Zu griff auf Daten und Informationen anderer Funktionseinheiten und Systeme, wie z. B. Umweltgrößen, Fahrzustandsgrößen, Fahrzeuggrößen und Benutzergrößen eine optimal an die jewei ligen Gegebenheiten angepaßte Fahrzeugsteuerung durchzufüh ren.

Fig. 2 zeigt dazu allgemein eine Daten- und/oder Programm struktur bzw. Softwarearchitektur, die unabhängig von der zugrunde liegenden Hardwarekonfiguration eingesetzt werden kann und/oder mit einfachen Mitteln und geringem Aufwand an diese angepaßt werden kann. Die sich in der Software wider spiegelnde Funktionalität ist so strukturiert. Die Grundele mente dieser Struktur sind Komponenten, die sich an Fahr zeug- bzw. Motorkomponenten orientieren, sogenannte Fahr zeugkomponenten. Weiterhin sind koordinierende Komponenten, sogenannte Koordinationskomponenten enthalten, die das Zu sammenwirken der Komponenten zur Durchführung von Steuerauf gaben koordinieren. Außerdem sind noch Komponenten enthal ten, die nicht an Hardware, sondern an Funktionen orientiert sind, sogenannte Funktionskomponenten, die also Funktionen repräsentieren. Die Schnittstellen jeder Komponente sind als Nachrichten definiert. Durch diese Nachrichten können einer seits Informationen abgefragt werden, gekennzeichnet durch ein Fragezeichen oder vorgegeben werden, gekennzeichnet durch ein Ausrufezeichen. Die Richtung der Nachrichtenüber tragung ist durch den Pfeil symbolisiert. Die Nachrichten in Fig. 2 sind mit 414 bis 416, 408 bis 410, 421 bis 423 sowie 421a bis 423a sowie 306 dargestellt. Die Bezeichnungen der Komponenten 300 bis 305 und 400 bis 407, 411 bis 413 und 417 bis 420 werden gleichzeitig im weiteren als deren erste Ken nungen eingesetzt.

Generell können die Kennungen aber als einstellig oder mehr stellig, als Zahl, Buchstaben, Zahl- und Buchstabenkombina tion usw. realisiert sein.

So ist das Fahrzeuggesamtsystem in eine Komponente Fahrzeug, eine Komponente Fahrzeugkoordinator, Karosserie und Innen raum 301, Fahrzeugbewegung 302, Bordnetz 303 und Antrieb 304 angeschlossen bzw. diesen zugeordnet. Diesen Komponenten sind weitere Komponenten zugeordnet. Dem Bordnetz 303 sind beispielsweise Schaltmittel 411 wie Startschalter oder Zün dung, Generator 412 sowie wenigstens eine Batterie 413 bzw. deren Funktionen zugeordnet. Die Komponente Bordnetz 303 fragt dabei von 411 die Startfreigabe 414 ab. Ebenso wird von Komponente 413 die Leistung mit 416 abgefragt. Die Lei stung wird mit 415 von der Komponente Bordnetz 303 an die Komponente Generator 412 übermittelt. Bei der Komponente Fahrzeugbewegung 302 sind die Funktionalitäten bzw. Hardwa rekomponenten für Vortrieb 405, Bremse 406 und Lenkung 407 zugeordnet. Ebenso ist ein Koordinator Fahrzeugbewegung 404 zugeordnet. Der Vortrieb gibt über eine Nachricht 408 das Moment an die Fahrzeugbewegung 302 vor. Die Fahrzeugbewegung 302 fragt über Nachricht 409 die Bremsinformation von Kompo nente 406 ab. Ebenso fragt die Fahrzeugbewegung 302 mittels Nachricht 410 die Leistung bzw. Leistungsaufnahme der Len kung 407 ab. Der Komponente 301 Karosserie und Innenraum sind beispielsweise die Komponenten Komfortelektronik 400, Klimaanlage 401, Telekommunikation und Multimedia 402 sowie Anzeigeelemente 403 zugeordnet. Die Komponente Fahrzeug fragt von der Komponente Antrieb 304 bzw. Antriebsstrang über Nachricht 306 die Leistung ab. Dem Antrieb sind die Komponenten 417 Antriebskoordinator, 418 Getriebe, 419 Wand ler, 420 Motor zugeordnet. Über Nachricht 421 wird durch Komponente 304 die Ganginformation von Komponente 418 Ge triebe abgefragt, gleichzeitig ist die Übersetzung in Kompo nente 421a durch Antrieb 304 an Getriebe 418 vorgebbar. Die Komponentenschnittstelle zwischen Komponente 304 und 419 ist durch Nachricht 422, die Abfrage des Kraftschlusses und op tional die Vorgabe des Schlupfes mit Nachricht 422a defi niert. Ebenso erfolgt über die Schnittstelle 423 bzw. 423a die Vorgabe des Momentes bzw. der Drehzahl an die Motorkom ponente 420.

Wie schon genannt, ist die Komponentenaufteilung beispiel haft durchgeführt und kann ebenso noch weiter verfeinert werden. Die Bezeichnungen der Komponenten 300 bis 305 usw. werden im weiteren der Übersichtlichkeit halber als deren Kennungen eingesetzt. Dies bedeutet, daß jede Komponente der Architektur eine eindeutige erste Kennung, insbesondere eine Kennzahl eben 300 bis 305, 400 bis 407, 411 bis 413, 417 bis 420 erhält. Diese erste Kennung wird im weiteren allgemein mit Kennung 1 K1 bezeichnet. Die jeweilige Basis- und Funk tionsvariante der entsprechenden Ausführungsform wird eine Kennung 2 K2 für jede Komponente zugeordnet. Diese Kennung K2 zerfällt dabei eine Kennung K2b für die Basisvariante und K2f für die Funktionsvariante. Zur eindeutigen Identifikati on der Stellung jeder Komponente innerhalb der Architektur und deren funktionalen Inhalt wird für jede Komponente ein Kennungsblock KB generiert. Der Kennungsblock der Komponente Bordnetz KB303 ist somit zusammengesetzt aus einer Kennung K2 mit K2b beispielsweise 00, K2f beispielsweise 01, der Kennung K1 für Bordnetz 303 sowie einer Kennung der zugeord neten Komponente Fahrzeug K1Z 300. Der Kennungsblock KB für das Bordnetz lautet somit:

300 303 01 00

Für die Komponente Motor 420 lautet der Kennungsblock KB420 mit einer Basisvariante 02 und einer Funktionsvariante 04 beispielsweise:

304 420 04 02

Allgemein ist der Kennungsblock KB aus der Kennung der zuge ordneten Komponente K1Z (bei einer hierarchischen System der übergeordneten Komponente) sowie der Kennung der zu be schreibenden Komponente selbst K1 und deren Basis und Funk tionsvariantenkennung K2 (K2b, K2f) zusammengesetzt:

K1Z K1 K2f K2b

Dieser Kennungsblock KB wird für jede Komponente durch eine Hilfskomponente generiert. Diese Hilfskomponente kann in Software oder Hardware realisiert sein und entweder als ei gene Komponente in der Architektur dargestellt sein oder in einer Zentralkomponente, beispielsweise Fahrzeug 300 enthal ten sein. Diese Tool kann aber auch extern in einer Steuer einheit in den Makelauf eingebunden sein und speichert alle Kennungsblöcke KB an einer definierten Adresse in einem Speicher einer Steuereinheit, beispielsweise aus Fig. 1, insbesondere im hexadezimalen File ab. Dadurch läßt sich je derzeit eine im Feld befindliche Software anhand des Ken nungsblocks schnell identifizieren.

Eine weitere Hilfskomponente oder die eben erwähnte Hilfs komponente könnte in einer vorteilhaften Weiterbildung diese Kennungsblöcke bzw. Kennungen auslesen und beispielsweise grafisch die Architektur anzeigen. Dies kann einerseits bei der Applikation hilfreich sein oder auch über Anzeigeelemen te 403 die Fehleranzeige im Fahrzeug für die Fahrzeugin sassen ermöglichen. Ebenso sind die Strukturen weiteren Per sonen, insbesondere Werkstattpersonal besser nachvollzieh bar.

In einer weiteren vorteilhaften Ausgestaltung kann so die Architektur von vornherein mit ihren funktionalen Varianten vorgegeben werden. Im Makelauf kann dann immer die Sollar chitektur mit der Istarchitektur auf Unterschiede verglichen werden, worauf eine Korrektur vorgenommen werden kann.

Weiterhin können grundlegende Beziehungen in der Architektur z. B. die Zuordnung zur Komponente Motor 420 zur Komponente Antrieb bzw. Antriebsstrang 304 bei Entwicklung der Software oder deren Steuerungsaufgabe überwacht und auf Konsistenz überprüft werden. Dies kann beispielsweise durch eine Checksummenbildung der Kennungen insbesondere wenn es sich um Kennzahlen handelt dieser Grundbeziehung oder durch Ver gleichsroutine erfolgen.

Durch das hier beschriebene Verfahren kann auch eine Softwa restruktur bzw. Architektur allgemein im Steuergerät nachge wiesen werden.

Eine weitere vorteilhafte Ausgestaltung dehnt das Verfahren auch auf die Schnittstellen jeder Komponente, also die Kom ponentenschnittstellen 306 bzw. 414 bis 416, 408 bis 409 usw. aus. Die Schnittstellen jeder Komponente sind dabei als Nachrichten definiert. Nachrichten, die von der Komponente versendet werden, haben in ihrem Namen den Namen bzw. die Kennung der Komponente. Welche Nachrichten aber empfangen werden, geht üblicherweise nur aus dem Softwarecode bzw. aus den Dokumentationen hervor. Vorteilhafter Weise wird nur ein Hilfsmittel bzw. eine Hilfskomponente kreiert, welches bei spielsweise für die Applikation eine Datei mit Informationen bezüglich der Komponentenschnittstellen erzeugt. Dabei kön nen einzelne Kennungen bis hin zu den gesamten Kennungsblöc ken der jeweiligen Komponente mit übertragen werden. Durch diese Maßnahme vereinfacht sich der Integrationstest und vor allem insbesondere die Applikation selbst. Insbesondere in der Applikation könnte über die Eingabe des Komponentenna mens bzw. der Komponentenkennung alle Nachrichten, die von der Komponente benutzt werden, angezeigt werden. Insbesonde re bei der Applikation sind so über wenige Eingaben am Ap plikationstool alle Informationen über die Funktionalität der Komponente sichtbar. Somit wird dann die Dokumentation eigentlich überflüssig bzw. es wird eine lückenhafte Doku mentation bezüglich ihrer Daten und Nachrichten sehr schnell erkannt.

Claims

1. Verfahren zur Steuerung eines Fahrzeugs, welches in einer Daten- und/oder Programmstruktur dargestellt wird, wobei die Daten- und/oder Programmstruktur Fahrzeugkomponenten, Koordinationskomponenten und Funktionskomponenten sowie Komponentenschnittstellen umfaßt, wobei die Komponenten einander zugeordnet sind und jede Komponente eine Basis variante und Funktionsvarianten besitzt, dadurch gekenn zeichnet, daß jeder Komponente eine erste Kennung eindeu tig zugeordnet wird, wobei der Basisvariante und der je weiligen Funktionsvariante eine zweite Kennung zugeordnet ist und ein Kennungsblock für jede Komponente, der die erste Kennung der jeweiligen Komponente, die zweite Ken nung sowie die erste Kennung einer zugeordneten Komponen te umfaßt, zur Fahrzeugsteuerung eingesetzt wird.

2. Verfahren nach Anspruch 1, dadurch gekennzeichnet, daß die Komponentenschnittstellen als Nachrichten, welche zwischen den Komponenten ausgetauscht werden, ausgebildet sind, und die Nachrichten wenigstens eine Kennung des Kennungsblockes der absendenden Komponente und/oder die Kennung der empfangenen Komponente enthält.

3. Verfahren nach Anspruch 1, dadurch gekennzeichnet, daß die Komponentenschnittstellen als Nachrichten, welche zwischen den Komponenten ausgetauscht werden, ausgebildet sind und die Nachrichten den Kennungsblock der absenden den und/oder der empfangenen Komponente enthalten.

4. Verfahren nach Anspruch 1, dadurch gekennzeichnet, daß eindeutige Zuordnungen zwischen Komponenten durch Prüfung der Kennungsblöcke gesichert werden und bei Ermittlung eines Fehlers eine Fehlerreaktion erzeugt wird.

5. Verfahren nach Anspruch 1, dadurch gekennzeichnet, daß alle Kennungsblöcke an einer definierten Adresse in einem Speicherbereich einer Steuereinheit zur Steuerung des Fährzeugs abgelegt sind, wobei diese durch eine Hilfskom ponente erzeugt und in dem Speicherbereich abgelegt wer den.

6. Verfahren nach Anspruch 1, dadurch gekennzeichnet, daß die Daten- und/oder Programmstruktur unter Verwendung der Kennungsblöcke an einem Ausgabe bzw. Anzeigemittel ange zeigt wird.

7. Elektronisches System für ein Fahrzeug, bestehend aus Fahrzeugkomponenten, Koordinationskomponenten und Funkti onskomponenten, wobei die Komponenten über Komponenten schnittstellen Nachrichten austauschen und die Komponen ten einander zugeordnet sind, wobei jede Komponente eine Basisvariante und Funktionsvarianten besitzt, dadurch ge kennzeichnet, daß jeder Komponente eine erste Kennung eindeutig zugeordnet ist und jeder Basis- und Funktions variante eine zweite Kennung zugeordnet ist und eine Hilfskomponente vorgesehen ist, die für jede Komponente deren erste Kennung und die erste Kennung einer zugeord neten Komponente und deren zweite Kennung zu einem Ken nungsblock zusammenfaßt und die Kennungsblöcke in einem Speicherbereich eines Speichers einer Steuereinheit zur Steuerung des Fahrzeugs ablegt.