DE10052571A1 - System zur Steuerung von Betriebsabläufen - Google Patents

Abstract

System zur Steuerung von Betriebsabläufen, insbesondere bei einem Fahrzeug, wobei das System zur Steuerung der Betriebsabläufe Programmmodule enthält und zur Steuerung unterschiedliche Programmstände mit unterschiedlichen Programmmodulen und/oder gleichen Programmmodulen unterschiedlichen Inhalts einsetzbar sind, wobei die Programmmodule nachgebildet werden und die nachgebildeten Programmmodule mit einer graphischen Schale mit Eingabemöglichkeiten versehen werden, wobei die Programmmodule eines neuen Programmstandes aus den Programmmodulen und den nachgebildeten Programmmodulen sowie den möglichen Eingaben automatisch gebildet werden.

Description

Stand der Technik

Die Erfindung betrifft ein System zur Steuerung von Betriebsabläufen, insbesondere bei einem Fahrzeug, wobei das System zur Steuerung der Betriebsabläufe Programmmodule enthält, gemäß den Oberbegriffen der unabhängigen Ansprüche.

Für die vollständige Konfiguration der Eigenschaften eines modernen RISC-Controllers müssen unzählige Register beschrieben werden. Dieser Vorgang erfolgt heute anhand zahlreicher Konfigurationsdateien, welche "von Hand" konfiguriert werden.

Die Vielzahl an frei definierbaren Werten, das Beachten von internen Abhängigkeiten sowie die Einhaltung von Regeln machen den Konfigurationsprozess zu einem äußerst schwierigen und komplexen Vorgang, der sich vor allem auf den Zeitaufwand und die Konfigurationsfehler auswirkt.

So zeigt sich, dass der Stand der Technik nicht immer optimale Ergebnisse zu liefern vermag, woraus sich ergibt, dass die vorstehend genannte Situation verbessert werden soll.

Die fortlaufende Weiterentwicklung von Funktionalitäten und die steigende Komplexität des Gesamtsystems erfordern nunmehr neue Konfigurationsmechanismen.

Vorteile der Erfindung und Beschreibung der Ausführungsbeispiele

Die Erfindung wird nachfolgend anhand der Beschreibung und der Figuren erläutert, woraus sich neben den genannten noch weitere Vorteile und vorteilhafte Ausgestaltungen ebenso wie aus den Ansprüchen ergeben.

Die Erfindung geht aus von einem System zur Steuerung von Betriebsabläufen, insbesondere bei einem Fahrzeug, wobei das System zur Steuerung der Betriebsabläufe Programmmodule enthält und zur Steuerung unterschiedliche Programmstände mit unterschiedlichen Programmmodulen und/oder gleichen Programmodulen unterschiedlichen Inhalts einsetzbar sind.

Von Vorteil ist, dass die Programmmodule nachgebildet werden und die nachgebildeten Programmodule mit einer graphischen Schale mit Eingabemöglichkeiten versehen werden, wobei die Programmmodule eines neuen Programmstandes aus den Programmmodulen und den nachgebildeten Programmmodulen sowie den möglichen Eingaben automatisch gebildet werden.

Weiterhin von Vorteil ist, dass die Programmmodule in einen hardwareabhängigen und einen hardwareunabhängigen Anteil aufgeteilt sind, und der hardwareabhängige Anteil als Hardwarekapsel zusammengefasst wird, wobei die Hardwarekapsel eines neuen Programmstandes aus der Hardwarekapsel, der nachgebildeten Hardwarekapsel und den möglichen Eingaben gebildet wird.

Ebenso von Vorteil ist, dass in den nachgebildeten Programmmodulen oder der nachgebildeten Hardwarekapsel mit der graphischen Schale mit Eingabemöglichkeiten zusätzlich Regeln zur Bildung der Programmmodule oder der Hardwarekapsel eines neuen Programmstandes enthalten sind und die Programmmodule oder die Hardwarekapsel des neuen Programmstandes entsprechend der Regeln gebildet werden. Die Verbindung kann dabei leitungsgebunden wie leitungslos ausgeführt sein, was bedeutet, das z. B. ein SPI, CAN oder auch z. B. ein Funkbus dafür Verwendung finden können. Die Verwendete Verbindung ist demnach nicht als einschränkend im Sinne der Erfindung zu verstehen.

Als Hardware ist beispielsweise ein in Fig. 6 dargestelltes Steuergerät zugrunde gelegt, welches z. B. zur Motorsteuerung, Getriebesteuerung, Bremsensteuerung, usw. bei einem Fahrzeug eingesetzt werden kann.

Mit der modernen Digitaltechnik ergeben sich vielfältige Möglichkeiten zur Steuerung und Regelung im Kraftfahrzeug. Viele Einflussgrößen können gleichzeitig mit einbezogen werden, sodass die Systeme optimal betrieben werden können. Das Steuergerät empfängt die elektrischen Signale der Sensoren, wertet sie aus und berechnet die Ansteuersignale für die Stellglieder (Aktoren). Das Steuerungsprogramm ist in einem Speicher abgelegt. Die Ausführung des Programms übernimmt ein Mikrocontroller. Die Bauteile des Steuergeräts werden "Hardware" genannt.

Sensoren bilden neben den Stellgliedern (Aktoren) als Peripherie die Schnittstelle zwischen dem Fahrzeug und dem Steuergerät als Verarbeitungseinheit. Die elektrischen Signale der Sensoren werden dem Steuergerät über Kabelbaum und Steckverbinder zugeführt. Diese Signale können unterschiedliche Formen haben:
Analoge Eingangssignale können jeden beliebigen Spannungswert innerhalb eines bestimmten Bereichs annehmen. Beispiele für physikalische Größen, die als analoge Messwerte bereitstehen, sind die angesaugte Luftmasse, Batteriespannung, Saugrohr- und Ladedruck, Kühlwasser- und Ansauglufttemperatur. Sie werden von Analog/Digitalwandlern (A/D-Wandlern) im Mikrocontroller des Steuergeräts in digitale Werte umgeformt, mit denen der Mikroprozessor rechnen kann. Die maximale Auflösung dieser Signale erfolgt in 5 mv Stufen/Bit (ca. 1000 Stufen).

Digitale Eingangssignale besitzen nur zwei Zustände, "High" (logisch 1) und "Low" (logisch 0). Beispiele für digitale Eingangssignale sind Schaltsignale (Ein/Aus) oder digitale Sensorsignale wie Drehzahlimpulse eines Hall- oder Feldplattensensors. Sie können vom Mikrocontroller direkt verarbeitet werden.

Pulsförmige Eingangssignale von induktiven Sensoren mit Informationen über Drehzahl und Bezugsmarke werden in einem eigenen Schaltungsteil im Steuergerät aufbereitet. Dabei werden Störimpulse unterdrückt und die pulsförmigen Signale in digitale Rechtecksignale umgewandelt.

Signalaufbereitung

Die Eingangssignale werden mit Schutzbeschaltungen auf zulässige Spannungspegel begrenzt. Das Nutzsignal wird durch Filterung weitgehend von überlagerten Störsignalen befreit und gegebenenfalls durch Verstärkung an die zulässige Eingangsspannung des Mikrocontrollers angepasst (0 . . . 5 V). Je nach Integrationsstufe kann die Signalaufbereitung teilweise oder auch ganz bereits im Sensor stattfinden.

Signalverarbeitung

Das Steuergerät ist die Schaltzentrale für die Funktionsabläufe der Motorsteuerung. Im Mikrocontroller laufen die Steuer- und Regelalgorithmen ab. Die von den Sensoren und den Schnittstellen zu anderen Systemen bereitgestellten Eingangssignale dienen als Eingangsgrößen. Sie werden im Rechner nochmals plausibilisiert. Mit Hilfe des Programms werden die Ausgangssignale berechnet.

Mikrocontroller

Der Mikrocontroller ist das zentrale Bauelement eines Steuergeräts. Er steuert dessen Funktionsablauf. Im Mikrocontroller sind außer der CPU (Central Processing Unit, d. h. zentrale Recheneinheit) noch Eingangs- und Ausgangskanäle, Timereinheiten, RAM, ROM, serielle Schnittstellen und weitere periphere Baugruppen auf einem Mikrochip integriert. Ein Quarz taktet den Mikrocontroller.

Programm- und Datenspeicher

Der Mikrocontroller benötigt für die Berechnungen ein Programm - die sogenannte "Software". Sie ist in Form von binären Zahlenwerten, die in Datensätze gegliedert sind, in einem Programmspeicher abgelegt. Die CPU liest diese Werte aus, interpretiert sie als Befehle und führt diese Befehle der Reihe nach aus.

Das Programm ist in einem Festwertspeicher (ROM, EPROM oder Flash-EPROM) abgelegt. Zusätzlich sind variantenspezifische Daten (Einzeldaten, Kennlinien und Kennfelder) in diesem Speicher vorhanden. Hierbei handelt es sich um unveränderliche Daten, die im Fahrzeugbetrieb nicht verändert werden können. Sie beeinflussen die Steuer- und Regelablaufe des Programms.

Der Programmspeicher kann im Mikrocontroller integriert und je nach Anwendung noch zusätzlich in einem separaten Bauteil erweitert sein (z. B. durch ein EPROM oder Flash-EPROM).

ROM

Programmspeicher können als ROM (Read Only Memory) ausgeführt sein. Das ist ein Lesespeicher, dessen Inhalt bei der Herstellung festgelegt wird und danach nicht wieder geändert werden kann. Die Speicherkapazität des im Mikrocontroller integrierten ROMs ist begrenzt. Für komplexe Anwendungen ist ein zusätzlicher Speicher erforderlich.

EPROM

Das EPROM (Erasable Programmable ROM, d. h. lösch- und programmierbares ROM) kann durch Bestrahlen mit UV-Licht gelöscht und mit einem Programmiergerät wieder neu beschrieben werden. Das EPROM ist meist als separates Bauteil ausgeführt. Die CPU spricht das EPROM über den Adress-/Datenbus an.

Flash-EPROM (FEPROM)

Das Flash-EPROM wird oft nur "Flash" genannt. Es ist auf elektrischem Wege löschbar. Somit können die Steuergeräte in der Kundendienst-Werkstatt umprogrammiert werden, ohne es öffnen zu müssen. Das Steuergerät ist dabei über eine serielle Schnittstelle mit der Umprogrammierstation verbunden.

Enthält der Mikrocontroller zusätzlich ein ROM, so sind dort die Programmierroutinen für die Flash-Programmierung abgelegt. Flash-EPROMs können mittlerweile auch zusammen mit dem Mikrocontroller auf einem Mikrochip integriert sein (ab EDC16).

Das Flash-EPROM hat aufgrund seiner Vorteile das herkömmliche EPROM weitgehend verdrängt.

Variablen- oder Arbeitsspeicher

Ein solcher Schreib-/Lesespeicher ist notwendig, um veränderliche Daten (Variablen), wie z. B. Rechenwerte und Signalwerte zu speichern.

RAM

Die Ablage aller aktuellen Werte erfolgt im RAM (Random Access Memory, d. h. Schreib-/Lesespeicher). Für komplexe Anwendungen reicht die Speicherkapazität des im Mikrocontroller integrierten RAMs nicht aus, so dass ein zusätzlicher RAM-Baustein erforderlich ist. Er ist über den Adress-/Datenbus an den Mikrocontroller angeschlossen. Beim Ausschalten des Steuergeräts über das Zündschloss verliert das RAM den gesamten Datenbestand (flüchtiger Speicher).

EEPROM (auch E²PROM genannt)

Das RAM verliert seine Information, wenn es von der Spannungsversorgung getrennt wird (z. B. bei ausgeschalteter Zündung). Daten, die nicht verloren gehen dürfen (z. B. Codes für die Wegfahrsperre und Daten des Fehlerspeichers), müssen dauerhaft in einem nicht flüchtigen Dauerspeicher abgelegt werden. Das EEPROM ist ein elektrisch löschbares EPROM, bei dem im Gegensatz zum Flash-EPROM jede Speicherzelle einzeln gelöscht werden kann. Es ist auch für eine höhere Anzahl an Schreibzyklen designed. Somit ist das EEPROM als nichtflüchtiger Schreib-/Lesespeicher einsetzbar.

ASIC

Wegen der immer größer werdenden Komplexität der Steuergerätefunktionen reichen die am Markt erhältlichen Standard-Mikrocontroller nicht aus. Abhilfe schaffen hier ASIC-Bausteine (Application Specific Integrated Circuit, d. h. anwendungsbezogene integrierte Schaltung). Diese ICs (Integrated Circuit) werden nach den Vorgaben der Steuergeräteentwicklung entworfen und gefertigt. Sie enthalten beispielsweise ein zusätzliches RAM, Eingangs- und Ausgangskanäle und sie können PWM-Signale erzeugen und ausgeben (siehe unten).

Überwachungsmodul

Das Steuergerät verfügt über ein Überwachungsmodul. Der Mikrocontroller und das Überwachungsmodul überwachen sich gegenseitig durch ein sogenanntes "Frage und Antwort Spiel". Wird ein Fehler erkannt, so können beide unabhängig voneinander die Einspritzung abschalten.

Ausgangssignale

Der Mikrocontroller steuert mit den Ausgangssignalen Endstufen an, die üblicherweise genügend Leistung für den direkten Anschluss der Stellglieder (Aktoren) liefern. Es ist auch möglich, dass die Endstufe ein Relais ansteuert. Die Endstufen sind gegenüber Kurzschlüssen gegen Masse oder der Batteriespannung sowie gegen Zerstörung infolge elektrischer oder thermischer Überlastung geschützt. Diese Fehler sowie aufgetrennte Leitungen werden durch den Endstufen-IC erkannt und dem Mikrocontroller gemeldet.

Schaltsignale

Mit den Schaltsignalen können Stellglieder ein- und ausgeschaltet werden (z. B. Motorlüfter).

PWM-Signale

Digitale Ausgangssignale können als PWM-Signale ausgegeben werden. Diese "Puls-Weiten-Modulierten" Signale sind Rechtecksignale mit konstanter Frequenz aber variabler Einschaltzeit (Bild 3). Mit diesen Signalen können Stellglieder (Aktoren) in beliebige Arbeitsstellungen gebracht werden (z. B. Abgasrückführventil, Lüfter, Heizelemente, Ladedrucksteller).

Kommunikation innerhalb des Steuergeräts

Die peripheren Bauelemente, die den Mikrocontroller in seiner Arbeit unterstützen, müssen mit diesem kommunizieren können. Dies geschieht über den Adress/Datenbus. Der Mikrocontroller gibt über den Adressbus z. B. die RAM- Adresse aus, deren Speicherinhalt gelesen werden soll. Über den Datenbus werden dann die der Adresse zugehörigen Daten übertragen. Frühere Entwicklungen im Kfz-Bereich kamen mit einer 8-Bit-Busstruktur aus. Das heißt, der Datenbus besteht aus acht Leitungen, über den 256 Werte übertragen werden können. Mit dem bei diesen Systemen üblichen 16-Bit- Adressbus können 65 536 Adressen angesprochen werden. Komplexe Systeme erfordern heutzutage 16 oder sogar 32 Bit für den Datenbus. Um an den Bauteilen Pins einzusparen, können Daten- und Adressbus in einem Multiplexsystem zusammengefasst werden, d. h. Adresse und Daten werden zeitlich versetzt übertragen und nutzen gleiche Leitungen.

Für Daten, die nicht so schnell übertragen werden müssen (z. B. Fehlerspeicherdaten), werden serielle Schnittstellen mit nur einer Datenleitung eingesetzt.

EOL-Programmierung

Die Vielzahl von Fahrzeugvarianten, die unterschiedliche Steuerungsprogramme und Datensätze verlangen, erfordert ein Verfahren zur Reduzierung der vom Fahrzeughersteller benötigten Steuergerätetypen. Hierzu kann der komplette Speicherbereich des Flash-EPROMs mit dem Programm und dem variantenspezifischen Datensatz am Ende der Fahrzeugproduktion programmiert werden (EOL, End Of Line Programmierung). Eine weitere Möglichkeit ist, dass im Speicher mehrere Datenvarianten (z. B. Getriebevarianten) abgelegt werden, die dann durch Codierung am Bandende ausgewählt werden. Diese Codierung wird im EEPROM abgelegt.

Im Weiteren wird die Erfindung nochmals erläutert:

Hardware-Kapselung

Die Hardware-Kapselung (engl.: hardware-encapsulation) eines Steuergerätes der Generation EDC 16/7 entspricht einer Software-Abstraktionsschicht, welche eine strikte Trennung zwischen Hardware und Anwender-Software (Fahrsoftware) vorsieht (Siehe Abb. 1: Software-Schichtenmodell der Plattformentwicklung ME9/EDC16).

Fig. 1a zeigt eine einfacher Darstellung der Abb. 1.

Offensichtlich besteht keine direkte Verbindung zwischen Hardware und Anwender-Software. Um an Hardware-Informationen zu gelangen, müssen Anwendungs-Funktionen entweder das Betriebssystem oder die Hardware-Kapselung benutzen. Das verfolgte Software-Konzept der Hardware-Kapselung verlangt eine vollkommene Einkapselung aller Hardware- Funktionen in einer schlanken Schnittstelle (Siehe EDC16/7 Hardwarekapselung). Gemäß diesem Ansatz sind direkte Hardware-Zugriffe für die Anwender-Software nicht mehr erforderlich, da die Hardware-Kapsel die Übergabe physikalischer Werte an einer definierten Schnittstelle, unabhängig von der Signalquelle, sowie konkurrenzfreie, elementare Funktionalität garantiert. Das Gesamtsystem wird dadurch wesentlich stabiler und vor allem sicherer.

Aufgrund dieses Konzeptes wird die Anwender-Software prinzipiell unabhängig von der verwendeten Hardware. Ändern sich die Hardware-Eigenschaften, so wirken sich diese nur auf die Hardware-Kapselung aus, nicht aber auf die darauf ablaufenden Anwendungs-Funktionen.

Somit wird letztendlich der einfache Aufbau eines Projektes mittels Hardwareanpassung ohne Eingriff in den Source-Code begünstigt. Dies wiederum steigert die Wartbarkeit des Systems.

Konfiguration der Hardware-Kapselung

Die Hardware-Kapselung des Controllers (Motorola MPC555) ist bezüglich der zu verarbeitenden Signale frei konfigurierbar (Siehe Abb. 2: Block-Diagramm MPC555). I/O-Operationen können z. B. über die multifunktionalen Controller-Pins und die Hardware-Komponenten DIO, TPU, QADC, SPI, etc. durchgeführt werden.

Die Aufgabe der Entwickler im Bereich Hardware-Kapselung besteht hauptsächlich darin, ein breites Spektrum an elementaren, redundanzfreien Funktionalitäten (Signalauswertungen, Diagnosefunktionen, etc.) zur Verfügung zu stellen. Diese Funktionalitäten werden in Form von Modulen realisiert und als Ganzes in einer Bibliothek bzw. in einem Archiv zusammengefaßt (Siehe Abb. 3: Modul- Struktur der Hardware-Kapsel).

Die Module der Hardware-Kapsel sind logisch und signalart­ orientiert definiert. Erst in zweiter Linie liegen diese Module auch physikalisch vor.

Die Anwender-Software, die in der nächsten Entwicklungsstufe auf dieser Plattform aufsetzt, kann nun verschiedenste Kundenanforderungen realisieren, wobei stets auf dieses eine Archiv zurückgegriffen wird. Die verwendeten Module bzw. Embedded Control-Funktionen lassen sich entsprechend den Anforderungen konfigurieren.

Üblicherweise erfolgt die Konfiguration über sogenannte Konfigurationsdateien. Diese Dateien beziehen sich auf den ANSI-C-Standard und treten mit den Dateiextensionen .h- und .c auf. Grundsätzlich wird jedes Modul durch die dazugehörige .h- und .c-Datei vollständig konfiguriert. Die interne Struktur dieser Dateien beinhaltet neben Konstantendeklarationen und Makrodefinitionen zahlreiche modulspezifische Konfigurationstabellen unterschiedlicher Länge und Breite. Die Spalten solcher Konfigurationstabellen entsprechen einzelnen Konfigurationsparametern wie Signalname, Modulname oder Pinnummer. In den Zeilen sind die dazugehörigen Werte enthalten. Die einzelnen Elemente der Tabellen können untereinander Abhängigkeiten aufweisen, von Tabellen in anderen Dateien abhängig sein oder deren Wertebereich beeinflussen.

Warum ein Konfigurationstool für die Hardware-Kapselung?

Zur vollständigen Konfiguration des Risc-Controllers müssen heute über 60 verschiedene Konfigurationsdateien korrekt beschrieben werden. Im allgemeinen enthalten solche Dateien eine Vielzahl an Definitionen und Konfigurationstabellen, die in ihrer Struktur auf unterschiedlichste Weise aufgebaut sein können und einwandfrei konfiguriert werden müssen. Durch die enorme Menge an konfigurierbaren variablen Werten wird die Komplexität dieses Konfigurations- und Integrationsprozesses offensichtlich. Die Komplexität spiegelt sich u. a. auch in dem damit verbundenen Zeitaufwand wieder, der für das Konfigurieren der Hardware-Kapselung aufgebracht werden muß.

Ein weiterer Aspekt liegt in der Nachfrage nach einer Update-Option für bereits bestehende Projekte. Die Entwickler des Hardware-Kapsel-Archives erstellen in gewissen Zeitabständen eine sich ändernde Bibliothek mit definierten Funktionalitäten. Diese definierten Funktionalitäten der Hardware-Kapsel werden für eine sogenannte Ablieferung (Die Ablieferung einer Hardware- Kapsel-Version entspricht dem Einfrieren einer Version mit festgelegtem Funktionsumfang) versioniert und mit einem Label versehen. Die Entwickler der Anwender-Software integrieren nun die Funktionalitäten einer bestimmten Hardware-Version in Bezug auf ihre spezifischen Projekte. Inzwischen werden allerdings neue Funktionalitäten entwickelt. Dadurch erscheinen weitere Hardware-Kapsel- Versionen, was wiederum für die Entwicklern der Anwender- Software ein erneutes Integrieren der Hardware-Kapsel bedeutet.

Damit bestehende Projekte in Zukunft zügig und sicher integriert werden können, soll ein Konfigurationstool, das heißt ein Software-Werkzeug, die Möglichkeit bieten, Projekte (Projektstadien) einzulesen und diese auf eine beliebige Version der Hardware-Kapsel updaten (dt.: erneuern, auffrischen) zu können.

Aus Gründen der Überschaubarkeit wird einerseits eine Vereinfachung des Konfigurationsprozesses angestrebt. Dies läßt sich jedoch nur mit einfachen und relativ uneffizienten C-Sprachkonstrukten verwirklichen. Andererseits resultieren die wachsenden Anforderungen in der Nachfrage nach effizienterem Code, was wiederum aufwendige und komplizierte C-Strukturen mit sich bringt.

Durch ein geeignetes Konfigurationstool soll dieser schwierige Integrations- und Konfigurationsprozeß, welcher praktisch nicht mehr ohne Spezialkenntnisse und Expertenwissen durchführbar ist, soweit als möglich automatisiert, vereinfacht und optimiert werden.

Außerdem soll durch optimale Algorithmen und möglichst ideale Strukturen in den Konfigurationsdateien, Code- Laufzeiten reduziert und die Performance des Systems (Laufzeitverbesserungen, Speichereinsparungen, etc.) erheblich verbessert werden. Die Konfiguration läßt sich weiterhin durch die Implementierung von Regelüberprüfungen maßgeblich stabiler und sicherer gestalten.

Konzeption der Systemarchitektur

Einordnung des Konfigurationstools in die Entwicklungskette. Bei der Entwicklung von Steuergeräte-Software wird zwischen zwei Bereichen unterschieden: Plattform und Projekt.

Die Plattform umfaßt Archive, in denen Plattform- Funktionalitäten in Form von .a-Dateien implementiert sind.

Um diese Archiv-Dateien verwenden werden zu können, müssen sie über entsprechende Konfigurationsdateien konfiguriert werden.

Der Bereich Projekt beinhaltet die Generierung bzw. Neuerstellung eines projekt-spezifischen Programmsystems. Unter Programmsystem ist hier ein aus mehreren Modulen zusammengesetztes Programm zu verstehen. Aus individuellem C-Quellcode und dazugehörigen Konfigurationsdateien macht ein nachfolgender Compiler .obj-Dateien. Diese .obj-Dateien enthalten Informationen über die zu integrierenden .a- Dateien aus den Archiven. Der Linker bildet nun aus den verschiedenen .obj-Dateien und den entsprechenden Archiv- Dateien sogenannte .elf-Dateien (Siehe Abb. 5: Entwicklungskette), die auf die Zielplattform geladen und ausgeführt werden können.

Hierbei bietet das Konfigurationstool dem Anwender eine komfortable, graphische Benutzerschnittstelle, um die vom jeweiligen Projekt benötigten Signale und Funktionalitäten konfigurieren zu können.

Grundprinzip

Das Konfigurationstool ist in der Lage, auf eingehende Daten (manuelle Eingaben oder Einlesen von Datenbank- Informationen) Plausibilitätsprüfungen und Regeln anzuwenden.

Die eingegebenen und überprüften Daten können entweder in der Datenbank gespeichert und weiterverarbeitet werden oder zu Konfigurationsdateien exportiert werden. (Abb. 5: Grundprinzip des Konfigurationstools).

Aufbau

In Anlehnung an die vorhandenen Strukturen der Hardware- Kapsel besteht auch das Konfigurationstool aus einem allgemeinen, modulunabhängigen Teil, der sogenannten Bibliothek (library), und einem modulspezifischen Teil, dem Modulbereich.

Der modulspezifische Teil des Konfigurationstools entspricht einer virtuellen Abbildung der Hardware-Kapsel-Module. Die Abbildung der hardware-nahen Modulstruktur auf eine graphische Benutzerschnittstelle ermöglicht die Durchführung der Konfiguration auf eine höheren Abstraktionsebene. Der Anwender muß sich nicht mehr mit C-Syntax und komplexen Regeln auseinandersetzen, er kann die benötigten Parameter über eine graphische Oberfläche eingeben, wobei die Eingabe der Werte und Einhaltung von Regeln vom Konfigurationstool überwacht und sichergestellt wird.

Claims (3)

1. System zur Steuerung von Betriebsabläufen, insbesondere bei einem Fahrzeug, wobei das System zur Steuerung der Betriebsabläufe Programmmodule enthält und zur Steuerung unterschiedliche Programmstände mit unterschiedlichen Programmmodulen und/oder gleichen Programmodulen unterschiedlichen Inhalts einsetzbar sind dadurch gekennzeichnet, dass die Programmmodule nachgebildet werden und die nachgebildeten Programmodule mit einer graphischen Schale mit Eingabemöglichkeiten versehen werden, wobei die Programmmodule eines neuen Programmstandes aus den Programmmodulen und den nachgebildeten Programmmodulen sowie den möglichen Eingaben automatisch gebildet werden.

2. System nach Anspruch 1, dadurch gekennzeichnet, dass die Programmmodule in einen hardwareabhängigen und einen hardwareunabhängigen Anteil aufgeteilt sind, und der hardwareabhängige Anteil als Hardwarekapsel zusammengefasst wird, wobei die Hardwarekapsel eines neuen Programmstandes aus der Hardwarekapsel, der nachgebildeten Hardwarekapsel und den möglichen Eingaben gebildet wird.

3. System nach Anspruch 1 oder 2, dadurch gekennzeichnet, dass in den nachgebildeten Programmmodulen oder der nachgebildeten Hardwarekapsel mit der graphischen Schale mit Eingabemöglichkeiten zusätzlich Regeln zur Bildung der Programmmodule oder der Hardwarekapsel eines neuen Programmstandes enthalten sind und die Programmmodule oder die Hardwarekapsel des neuen Programmstandes entsprechend der Regeln gebildet werden.