DE102009011431A1

DE102009011431A1 - Vorrichtung zur Steuerung und Regelung eines Antriebssystems

Info

Publication number: DE102009011431A1
Application number: DE200910011431
Authority: DE
Inventors: Jan Peter Dr.-Ing. Blath; Maiko Dr.-Ing. Garwon; Franz Dr.-Ing. Kallage; Nick Dr.-Ing. Weinhold; Abid Prof. Dr. Ali
Original assignee: IAV GmbH Ingenieurgesellschaft Auto und Verkehr
Current assignee: IAV GmbH Ingenieurgesellschaft Auto und Verkehr
Priority date: 2009-02-25
Filing date: 2009-02-25
Publication date: 2010-08-26

Abstract

Es ist Aufgabe der vorliegenden Erfindung, eine Vorrichtung zur Steuerung und Regelung eines Antriebssystems bereitzustellen, wobei bei einem Wechsel des Antriebssystems beziehungsweise einer damit verbundenen Änderung der Aktuatorik möglichst wenig Änderungsbedarf besteht. Diese Aufgabe wird erfindungsgemäß dadurch gelöst, dass eine Vorrichtung zur Steuerung und Regelung eines Antriebssystems, die einen Computerprogrammcode umfasst, wobei der Computerprogrammcode in mehrere Blöcke strukturiert ist, wobei die Blöcke Funktionen zur Steuerung und Regelung eines Antriebssystems als abgrenzbare Bestandteile des Computerprogrammcodes umfassen, mindestens einen Block mit einer Aktuator-Schnittstelle umfasst, welcher Funktionen zur Verarbeitung von Stellsignalen und deren Weiterleitung an die Aktuatoren/Endstufen zugeordnet sind, wobei die Aktuator-Schnittstelle zwei Ebenen umfasst, wobei die erste Ebene Funktionen zur Umwandlung von Stellsignalen in Eingangssignale von Funktionen zur Ansteuerung der Aktuatoren/Endstufen umfasst, wobei die erste und die zweite Ebene durch eine Laufzeitumgebung voneinander getrennt sind, wobei die zweite Ebene die Funktionen zur Ansteuerung der Aktuatoren/Endstufen umfasst.

Description

Die vorliegende Erfindung betrifft eine Vorrichtung zur Steuerung und Regelung eines Antriebssystems gemäß den Merkmalen des Patentanspruches 1.
Aus der DE 100 44 319 A1 ist es vorbekannt, zur Steuerung und/oder Regelung eines Fahrzeuges eingebettete Softwarelösungen einzusetzen, wobei so genannte Basisfunktionen und Betriebsfunktionen verwendet werden, wobei die Basisfunktionen unter anderem so genannte Kernfunktionen und Treibersoftware umfassen, also Funktionen, die steuereinheitsspezifisch sind, wobei die Betriebsfunktionen Funktionen umfassen, die das eigentliche Betriebsverhalten des Fahrzeuges bestimmen, wobei die Basisfunktionen und die Betriebsfunktionen derart voneinander getrennt sind, dass ein Hinzufügen oder Austauschen von Betriebsfunktionen möglich ist, ohne dass die Basisfunktionen geändert werden müssen. Erfolgt jedoch beispielsweise im Rahmen einer Weiterentwicklung des Antriebssystems eines Kraftfahrzeuges eine Änderung der Aktuatorik, ist davon auszugehen, dass sowohl Änderungen in den Betriebsfunktionen als auch Änderungen in den Basisfunktionen erforderlich sind.
Aufgabe
Es ist daher Aufgabe der vorliegenden Erfindung, eine Vorrichtung zur Steuerung und Regelung eines Antriebssystems bereitzustellen, wobei bei einem Wechsel des Antriebssystems beziehungsweise einer damit verbundenen Änderung der Aktuatorik möglichst wenig Änderungsbedarf besteht.
Lösung
Diese Aufgabe wird erfindungsgemäß dadurch gelöst, dass eine Vorrichtung zur Steuerung und Regelung eines Antriebssystems, die einen Computerprogrammcode umfasst, wobei der Computerprogrammcode in mehrere Blöcke strukturiert ist, wobei die Blöcke Funktionen zur Steuerung und Regelung eines Antriebssystems als abgrenzbare Bestandteile des Computerprogrammcodes umfassen, mindestens ei nen Block mit einer Aktuator-Schnittstelle umfasst, welcher Funktionen zur Verarbeitung von Stellsignalen und deren Weiterleitung an die Aktuatoren/Endstufen zugeordnet sind, wobei die Aktuator-Schnittstelle zwei Ebenen umfasst, wobei die erste Ebene Funktionen zur Umwandlung von Stellsignalen in Eingangssignale von Funktionen zur Ansteuerung der Aktuatoren/Endstufen umfasst, wobei die erste und die zweite Ebene durch eine Laufzeitumgebung voneinander getrennt sind, wobei die zweite Ebene die Funktionen zur Ansteuerung der Aktuatoren/Endstufen umfasst. Durch die erfindungsgemäße Trennung der Aktuator-Schnittstelle in zwei Ebenen wird der Vorteil erreicht, dass die der jeweiligen Ebene zugeordneten Funktionen von der jeweils kompetenten Seite entwickelt und bedatet werden können. Da das Know-how zu Aktuatoren praktisch immer auf der Seite eines Systemherstellers beziehungsweise -lieferanten liegt und das Know-how für die anwendungsorientierte Nutzung, beziehungsweise der jeweiligen Anwendung angepassten Verarbeitung/Bereitstellung von Stellsignalen bei dem jeweiligen Hersteller des Antriebssystems liegt, wie beispielsweise einem Fahrzeugherstellers (OEM), ist es durch die erfindungsgemäße Trennung der Ebenen möglich, dass sowohl Systemhersteller als auch OEM gezielt ihre Kompetenzen im Rahmen eines parallel stattfindenden Entwicklungsprozesses einbringen können.
Bevorzugt umfasst die erste Ebene für jeden einzelnen mit der Aktuator-Schnittstelle verbundenen Aktuator eine diesem Aktuator zugeordnete Komponente, welche die Funktionen zur Umwandlung der diesen Aktuator betreffenden Stellsignale in Eingangssignale der Funktionen zur Ansteuerung der Aktuatoren/Endstufen umfasst. Bevorzugt umfasst die zweite Ebene für jeden einzelnen mit der Aktuator-Schnittstelle verbundenen Aktuator ebenfalls eine diesem Aktuator zugeordnete Komponente, welche die Funktionen zur Ansteuerung der Aktuatoren/Endstufen umfasst. Insbesondere bestehen somit sowohl zwischen den einzelnen Funktionen, die jedem einzelnen Aktuator in der ersten Ebene zugeordnet sind, keine Querkopplungen, als auch zwischen den einzelnen Funktionen, die jedem einzelnen Aktuator in der zweiten Ebene zugeordnet sind, keine Querkopplungen. Somit ist erfindungsgemäß vorteilhaft eine einfache Anpassung der Software einer zu Grunde liegenden Vorrichtung zur Steuerung und Regelung eines Antriebssystems bei der Änderung der Aktuatorik möglich, da zwischen den einzelnen Funktionen der jeweiligen Ebenen der Aktuator-Schnittstelle keine Querkopplungen bestehen. Wird beispielsweise der Aktuator eines Herstellers durch einen Aktuator eines anderen Herstellers ersetzt, dann ist nur die der jeweiligen Ebene zugeordnete Funktion davon betroffen und nicht die Funktionen die in der jeweiligen Ebene für die verbleibenden Aktuatoren vorgesehen sind.
Erfindungsgemäß kann die Aktuator-Schnittstelle weiterhin mit einem Controller zusammenwirken, wobei der Controller Stellsignale bereitstellt, wobei der Controller in einzelne Module gegliedert ist, wobei die Module physikalisch beschreibbare Komponenten des Antriebssystems darstellen, wobei die der ersten Ebene für jeden einzelnen mit der Aktuator-Schnittstelle verbundenen Aktuator zugeordneten Komponenten ebenfalls in Module gegliedert sind, wobei die Gliederung dieser Module der Gliederung der Module des Controllers entspricht. Erfindungsgemäß ergibt sich dadurch der Vorteil einer leichten Identifizierbarkeit der jeweils zusammenwirkenden Bestandteile einer Vorrichtung zur Steuerung/Regelung eines Antriebssystems. Insbesondere im Rahmen der Entwicklung eines Antriebssystems ergeben sich auf diese Weise Erleichterungen, da eine einheitliche Gliederung der zusammenwirkenden Bestandteile einer Vorrichtung zur Steuerung/Regelung eines Antriebssystems vorliegt und sich für den Bearbeiter eine klare übersichtliche Struktur darstellt.
Weiterhin kann die zweite Ebene der Aktuator-Schnittstelle Funktionen zur Diagnose der Aktuatoren/Endstufen umfassen, wobei bevorzugt für jeden einzelnen mit der Aktuator-Schnittstelle verbundenen Aktuator eine Funktion zur Diagnose vorgesehen ist.
In einer Ausführung wirkt die erfindungsgemäße Aktuator-Schnittstelle mit einem Diagnose-Manager zusammen, wobei in Abhängigkeit des Ergebnisses der der zweiten Ebene der Aktuator-Schnittstelle zugeordneten Funktionen zur Diagnose der Aktuatoren/Endstufen mittels des Diagnose-Managers eine Verwaltung erfolgt, beispielsweise ein Ablegen einer Fehlerinformation in einem flüchtigen oder nichtflüchtigen-Speicher und gegebenenfalls einer Kommunikation der Fehlerinformation über einen Diagnosetester.
Insbesondere ist die Aktuator-Schnittstelle Bestandteil einer zur Steuerung und Regelung eines Antriebssystems aus mehreren Blöcken gebildeten modularen Struktur eines Computerprogrammcodes, wobei jeweils mindestens ein Block für

a.) eine Sensor-Schnittstelle,
b.) eine Aktuator-Schnittstelle,
c.) eine Kommunikations-Schnittstelle,
d.) einen Beobachter/eine Signalverarbeitung,
e.) einen Diagnose-Manager,
f.) einen Rekonfigurator,
g.) eine Diagnosefunktion,
h.) einen Controller,

Ausführungsbeispiel
Weitere vorteilhafte Ausgestaltungen der vorliegenden Erfindung sind dem nachfolgenden Ausführungsbeispiel sowie den abhängigen Patentansprüchen zu entnehmen.
Hierbei zeigen:
1: die erfindungsgemäße modulare Struktur zur Steuerung und Regelung eines Antriebssystems,
2: die erfindungsgemäße modulare Struktur als Bestandteil einer Vorrichtung zur Steuerung und Regelung eines Antriebssystems aus AUTOSAR-Sicht,
3: Details der Sensor-Schnittstelle,
4: die Darstellung des Signalflusses von einem gewandelten Sensorspannungswert bis zum Istwert,
5: Details der Aktuator-Schnittstelle,
6: Details zur Signalaufbereitung,
7: das Prinzip eines Zustandsbeobachters,
8: Details zum Beobachter/zur Signalverarbeitung,
9: Details zur Kommunikation innerhalb des Beobachters/der Signalverarbeitung,
10: Details zu einer Signalauswahl,
11: Details des Diagnose-Managers,
12: interne Kommunikation/Signalfluss innerhalb des Diagnose-Managers,
13: den Signalfluss innerhalb des Controllers,
14: Details zur Diagnosefunktion,
15: die zusätzliche Modulebene in der Diagnosefunktion,
16: die Kommunikation innerhalb der Diagnosefunktion,
17: Details zum Rekonfigurator,
18: Details zu Rekonfigurationsstrategien.
Gemäß 1 ist die erfindungsgemäße modulare Struktur zur Steuerung und Regelung eines Antriebssystems, das die Blöcke a.) bis h.) sowie weitere Blöcke i.) bis l.) umfasst, dargestellt. Der Block a.) stellt in der erfindungsgemäßen Struktur eine Sensor-Schnittstelle dar, die für die Grundverarbeitung von Sensorsignalen zuständig ist, wobei Funktionen, die dem Block a.) zugeordnet sind, dazu dienen, Hardwarebausteine für die Erfassung von Signalen anzusteuern, also beispielsweise eine A/D-Wandlung vorzunehmen, Umrechnungen elektrischer Signale in physikalische Größen, also beispielsweise eine Spannung in einen Druck umzurechnen sowie eine hardwarenahe Grunddiagnose und Plausibilisierung der gemessenen Signale vorzunehmen. Die dem Block a.) zugeordneten Funktionen sind hardwarenah und dienen quasi als Hardwareabstraktionsschicht. Der Block a.) ist mit Sensoren zum Austausch von Informationen/Daten sowie mit dem Block d.), also dem Beobachter beziehungsweise der Signalverarbeitung, verbunden, wie durch die beiden fett gedruckten Pfeile angedeutet. Eingangsgrößen des Blockes a.) sind die abgetasteten, quantisierten elektrischen Signale der Sensoren, die durch die Funktionen, die Block a.) zugeordnet sind, verarbeitet werden, so dass die Ausgangsgrößen des Blockes a.) die in physikalische Größen, wie Druck oder Temperatur, umgerechneten elektrischen Sensorsignale sind, die dem Block d.) zugeführt werden, wobei mittels des Beobachters/der Signalverarbeitung eine Korrektur/Adaption des erfassten Signals oder ein Vergleich mit modellierten Signalwerten erfolgen kann. Außerdem ist der Block a.) zum Austausch von Informationen/Daten mit dem Block e.), also dem Diag nose-Manager, verbunden, wie durch den Pfeil angedeutet, wobei in Abhängigkeit des Ergebnisses der in Block a.) durchgeführten Grunddiagnose und Plausibilisierung der gemessenen Signale mittels des Diagnose-Managers in Block e.) eine Verwaltung erfolgt, beispielsweise ein Ablegen einer Fehlerinformation in einem nicht flüchtigen Speicher und gegebenenfalls nach außen über einen Diagnosetester. Praktisch ergibt sich durch das Vorsehen des Blockes a.) in Verbindung mit den Blöcken d.) und e.) der Vorteil, dass wenn ein Sensor eines bestimmten Herstellers gegen einen Sensor eines anderen Herstellers ausgetauscht wird, nur der Block a.), also die Sensor-Schnittstelle und sonst keine weiteren Umfänge der Vorrichtung zur Steuerung und Regelung des Antriebssystems beeinflusst werden, also somit unverändert bleiben.
Der Block b.) stellt in der erfindungsgemäßen Struktur die Aktuator-Schnittstelle dar, die für die Endverarbeitung von Stellsignalen und deren Weiterleitung an die Aktuatoren bzw. Endstufen zuständig ist. Der Block b.) ist neben den jeweiligen Aktuatoren mit dem Block h.), also dem Controller, zum Austausch von Daten/Informationen verbunden, wie durch den fett gedruckten Pfeil angedeutet. In den Block b.) werden Stellsignale eingelesen, die in logischen oder physikalischen Einheiten vorliegen können und die in dem Block h.) gebildet werden. Die dem Block b.) zugeordneten Funktionen wandeln diese Stellsignale in Signale in geeigneter Form um, so dass diese an Endstufen zur Ansteuerung der Aktuatoren weitergeleitet werden können, wie durch den weiteren fett gedruckten Pfeil angedeutet. Die dem Block b.) zugeordneten Funktionen haben hauptsächlich die Aufgabe, eine Endverarbeitung von Stellsignalen vorzunehmen, einen Treiber für die Endstufen-Hardware zu bilden, einen Treiber für Aktuator-Hardware zu bilden und Endstufendiagnosen durchzuführen. Der Block b.) ist ferner zum Austausch von Informationen/Daten mit dem Block e.), also dem Diagnose-Manager, verbunden, wie durch den Pfeil angedeutet, wobei in Abhängigkeit des Ergebnisses der in Block b.) durchgeführten Diagnosen der Endstufen beziehungsweise der Aktuatoren mittels des Diagnose-Managers in Block e.) eine Verwaltung erfolgt, beispielsweise ein Ablegen einer Fehlerinformation in einem nicht flüchtigen Speicher und gegebenenfalls einer Kommunikation der Fehlerinformation nach außen über einen Diagnosetester. Außerdem ist der Block b.) zum Austausch von Informationen/Daten mit dem Block d.), also dem Beobachter/der Signalverarbeitung, verbunden, wie durch die beiden Pfeile angedeutet, wobei insbesondere aktuel le modellierte/beobachtete Prozessgrößen oder gemessene Signale von dem Block d.) an den Block b.) übermittelt werden.
Erfindungsgemäß vorteilhaft erfolgt mit Hilfe der Aufteilung in Block b.) und Block h.) eine Entkopplung von Reglerfunktionen und verwendetem Aktuator, beziehungsweise können mittels der Aufteilung des Blockes h.), dem Reglerfunktionen zugeordnet sind, und dem Block b.) Reglerfunktionen unabhängig vom verwendeten Aktuator realisiert werden. Ein Beispiel hierfür ist eine so genannte Raildruckregelung zur Einstellung eines bestimmten Druckwertes im Rail der Einspritzanlage einer Verbrennungskraftmaschine. Die Block h.) zugeordnete Reglerfunktion erzeugt als abstrakte Stellgröße einen Sollvolumenstrom durch die Hochdruckpumpe. Die Aktuator-Schnittstelle, also Block b.), berechnet aus dieser abstrakten Stellgröße eine Ansteuerung des Stellgliedes. Bei letzterem kann es sich beispielsweise um ein Mengensteuerventil oder in einem anderen Konzept um ein saugseitiges Dreiwegeventil handeln. Die Reglerfunktion bleibt damit unabhängig vom Pumpenkonzept und kann für verschiedene Kraftstoffsysteme verwendet werden.
Der Block c.) stellt in der erfindungsgemäßen Struktur eine Kommunikations-Schnittstelle dar, die eine Verbindung mit anderen Vorrichtungen zur Steuerung und Regelung eines Antriebssystems, also anderen Steuergeräten oder Einheiten, ermöglicht, die eine protokollbasierte Kommunikation, wie zum Beispiel CAN, CCP, XCP, FlexRay oder Diagnosetester, unterstützen. Dem Block c.) werden folglich Funktionen zugeordnet, die den Austausch von Daten oder Botschaften mit anderen Kommunikationspartnern vornehmen. Ferner ist hier auch die CAN-Überwachung, beispielsweise hinsichtlich Timeouts, unterzubringen. Der Block c.) ist demgemäß mit externen Kommunikationsnetzen, wie zum Beispiel dem CAN-Bus verbunden, wie durch den Doppelpfeil angedeutet. Außerdem ist Block c.) zur Kommunikation innerhalb der erfindungsgemäßen Struktur mit dem Block h.), also dem Controller, dem Block d.), also dem Beobachter/der Signalverarbeitung und dem Block e.), also dem Diagnose-Manager, verbunden, wie durch die Pfeile angedeutet. Über die Verbindung des Blockes c.) zu dem Block e.) können ferner Daten/Informationen hinsichtlich Diagnoseergebnissen anderer Steuergeräte oder Einheiten des Antriebssystems übermittelt werden, wie durch den Pfeil/Doppelpfeil angedeutet. Als Eingangsgrößen des Blockes c.) lassen sich folglich zusammenfassen, externe, beispielsweise über CAN empfangene Signale, gemessene oder modellierte Signale von Block d.), die weiter versandt werden sollen, Stellsignale von Block h.), die beispielsweise an ein weiteres Steuergerät versandt werden sollen und von Block e.) verwaltete Diagnoseergebnisse, wie beispielsweise Fehlerspeichereinträge. Als Ausgangsgrößen des Blockes c.) lassen sich zum Einen zusammenfassen, Signale, die nach außen versendet werden, wie zum Beispiel gemessene/modellierte Signale aus dem Block d.) zum Anderen Stellsignale aus dem Block h.) und weiterhin Diagnoseergebnisse aus dem Block e.). Ausgangssignale des Blockes c.) sind außerdem eingelesene externe Größen, wie beispielsweise die Fahrzeugrohgeschwindigkeit oder Momentensollwerte, welche über Block c.) an Block d.) weitergeleitet werden.
In der erfindungsgemäßen Struktur stellt der Block d.), also der Beobachter/die Signalverarbeitung, ein wesentliches Element dar, das über die reine regelungstechnische Grundfunktion eines Zustandsbeobachters hinausgeht. Letzterer ist bekanntlich durch ein mathematisches Modell charakterisiert, welches dieselben Eingangsgrößen erhält wie der zu beobachtende Prozess und den Zweck hat, nicht messbare Zustandsgrößen des Systems zu ermitteln. Die Ausgangsgrößen des Modells werden hierzu mit den gemessenen Ausgangsgrößen des Prozesses verglichen und die als Residuum bezeichnete Abweichung zwischen Messung und Modell wird zur Korrektur der modellierten Zustandsgrößen verwendet.
Die Funktionen, die Block d.) zugeordnet sind, dienen dazu, Block b.), Block h.) und Block g.) mit den erforderlichen Informationen über den Ist-Zustand von Antrieb und Fahrzeug zu versorgen, die erforderlichen Verbindungen sind als Pfeile in 1 dargestellt. Für die Realisierung modellgestützter Diagnosen wird insbesondere Block g.) mit den Beobachterresiduen versorgt. Der Ist-Zustand setzt sich aus gemessenen Signalen, beobachteten Größen und weiteren aus Messungen, Beobachtungen und den weiteren Block d.) zur Verfügung gestellten Signalen berechneten Größen zusammen. Es kann sich hierbei um wertkontinuierliche Signale wie Drehzahlen oder Drücke handeln, aber auch um wertdiskrete Information wie etwa die aktuelle Betriebsart eines Verbrennungsmotors oder ein Statusbit, welches die Betriebsbereitschaft einer Lambda-Sonde anzeigt. Damit geht die hier verwendete Definition des Ist-Zustandes über die regelungstechnische Definition hinaus, da nicht nur Zustandsgrößen ermittelt werden, welche die Dynamik des Gesamtsystems be schreiben, sondern auch weitergehende Information dem System bereitgestellt wird. Ein Beispiel für eine solche Information stellt die Zylinderfüllung dar, die sich aus Zustandsgrößen wie Saugrohrdruck usw. berechnet.
Mit anderen Worten haben die Funktionen, die dem Block d.) zugeordnet sind, die Aufgabe, den momentanen Ist-Zustand des zu steuernden und zu regelnden Antriebssystems mit Hilfe von Modellen zu beobachten. Hierbei werden beispielsweise vereinfachte nichtlineare dynamische Modelle eingesetzt, um anhand der Stellsignale und der Umweltbedingungen die messbaren und nichtmessbaren Zustandsgrößen des Systems zu schätzen. Modellierte messbare Zustände werden in diesem Zuge mit Messsignalen verglichen. Zur Übermittlung von Messsignalen ist Block d.) mit Block a.) verbunden, wie in 1 dargestellt. Aus diesem Vergleich gehen die sogenannten Residuen hervor, mit deren Hilfe eine Beobachterrückführung realisiert wird, welche die modellierten Zustandsgrößen korrigiert. Als Residuum wird ein berechneter Fehler, beispielsweise zwischen Modell und Messung, bezeichnet. Wird eine messbare Größe mit Hilfe eines mathematischen Modells berechnet, so stellt die Differenz zwischen gemessenem und modelliertem Wert das Residuum dar. Eine weitere Aufgabe der Funktionen, die dem Block d.) zugeordnet sind, ist die Beobachtung der Systemzustände, wobei diese beobachteten Zustände dazu verwendet werden können, nicht messbare Größen in der Steuerung und Regelung zu verwenden. Bei einem Sensorausfall können beobachtete Zustände als Ersatzwerte für Messgrößen verwendet werden.
Wie schon beschrieben ist es ferner Aufgabe der Funktionen, die dem Block d.) zugeordnet sind, die dem Block h.) und dem Block g.) zugeordneten Funktionen mit der Information über den Istzustand des Systems und den Residuen zu versorgen. Dazu ist Block d.) mit Block h.) und Block g.) zum Austausch von Daten/Informationen verbunden, so dass gemessene und/oder modellierte/beobachtete Signale übermittelt werden können, wie in 1 durch die Pfeile angedeutet, wobei die gemessenen und/oder modellierten/beobachteten Signale auch in einem gemeinsamen Bus zusammengefasst werden können. Ferner ermöglicht Block d.), dass sich die Funktionen, die dem Block h.), also dem Controller, zugeordnet sind, unabhängig von der Sensorkonfiguration realisieren lassen. Eine solche Entkopplung beziehungsweise Abstraktion der Sensorik bewirkt auf vorteilhafte Weise, dass bei einem Wechsel der Sensorkonfiguration, beispielsweise bei einem Wechsel des Antriebskonzeptes, aufgrund der festgelegten Schnittstelle zwischen Block d.) und Block h.) nur die Funktionen, die dem Block d.) zugeordnet sind, geändert werden müssen, und nicht die dem Block h.) zugeordneten Funktionen. Eine Änderung der Sensorkonfiguration schlägt sich somit nicht in einer Änderung der Reglerfunktionen nieder. Mit anderen Worten nimmt der Beobachter gemäß Block d.) eine Abstraktion der Sensorik vor und entkoppelt diese von den Reglerfunktionen im Controller, also von Block h.). Wenn sich beispielsweise im Zuge eines Projektwechsels die Sensorkonfiguration ändert, müssen nur die Funktionen, die Block d.) zugeordnet sind, angepasst werden. Die Funktionen, die dem Block h.) zugeordnet sind, bleiben unberührt, weil die festgelegte Schnittstelle zwischen Block d.) und Block h.) unverändert bleibt. Wie schon dargestellt, ist der Block d.) zum Austausch von Daten/Informationen ferner mit Block b.) verbunden, wobei insbesondere modellierte/beobachtete oder auch gemessene Signale von dem Block d.) an den Block b.) übermittelt werden, wie durch die Pfeile angedeutet.
Eine weitere Funktionalität von Block d.) stellt die Realisierung modell- oder signalbasierter Sensoradaptionsverfahren dar, welche den Einfluss von Messungenauigkeiten der Sensoren verringern können. Die Module und Funktionen in Block d.), also dem Beobachter, lassen sich naturgemäß einzelnen Hardwarekomponenten zuordnen. So gibt es im Zusammenhang mit einer verwendeten Verbrennungskraftmaschine ein Saugrohrmodell, ein Railmodell und so weiter. Es bleibt also immer eine sogenannte „Komponentensicht” erhalten, die eine schnelle Zuordnung von Modulen und Funktionen zu Hardware-Komponenten des Antriebssystems erlaubt. Im allgemeinen hat eine beobachterbasierte Struktur folgende Vorteile. Zum Einen ergibt sich eine Verbesserung der Regelqualität. So ist bei technischen Systemen nicht immer alles messbar. Für ein System höherer Ordnung kann die Regelgüte erheblich verbessert werden, wenn zusätzlich zu der Ausgangsrückführung auch die internen Systemzustände für die Stellsignalgenerierung herangezogen werden. Ein Beobachter, wie gemäß Block d.), bietet die Möglichkeit, interne Systemzustände ohne zusätzliche Sensorik zu rekonstruieren. Durch Rückführung der beobachteten Zustände kann die Regelqualität verbessert werden. Es werden also alle internen Systemzustände vom Beobachter gemäß Block d.) erfasst und stehen für die Regelung zur Verfügung. Auf diese Weise können leistungsfähige moderne Verfahren, wie bei spielsweise Zustandsregler, problemlos eingebunden werden. Die Verwendung dieser zusätzlichen Information kann zu höherer Regelqualität führen. Zum Anderen ergibt sich eine Verbesserung der Diagnosequalität. So werden anhand eines Beobachters, wie gemäß Block d.), geschätzte Zustände mit gemessenen Signalen verglichen. Wenn zur Laufzeit die Residuen zwischen beobachteten und gemessenen Signalen zuvor definierte Schwellwerte überschreiten, kann auf einen Fehlerfall geschlossen werden. Anhand von Residuen und dynamischen Modellen lassen sich bessere Diagnoseergebnisse, beispielsweise bzgl. Fehlererkennung, -pinpointing und -quantifizierung, erzielen. Pinpointing beschreibt dabei die Identifikation der kleinsten austauschbaren fehlerhaften Komponente des Antriebssystems. Es können also alle Sensorgrößen mit entsprechenden Modellgrößen verglichen werden. Die daraus resultierenden Residuen können für die Fehlerdiagnose verwendet werden. Leistungsfähige modellbasierte Diagnosetechniken können so realisiert werden. Diese Verfahren sind bezüglich der Diagnosetiefe aussagekräftiger als einfache signalbasierte Verfahren, wie sie gegenwärtig zur Anwendung kommen. Ferner ergibt sich eine erhöhte Fehlertoleranz und Zuverlässigkeit. So können Beobachterfunktionen, wie gemäß Block d.), als virtuelle Sensoren betrachtet werden, die im Fehlerfall Ersatzwerte für die ausgefallenen Sensoren liefern. So kann der Zuverlässigkeitsgrad des Gesamtsystems erhöht werden. Darüber hinaus ergibt sich ein Einsparpotential bei Sensorkosten, da die Beobachterfunktionen, wie gemäß Block d.), als virtuelle Ersatzsensoren betrachtet werden können. So ist es möglich, beispielsweise abhängig vom Ergebnis einer Beobachtbarkeitsanalyse, einige reale Sensoren einzusparen. Diese Einsparungen gehen aber auf Kosten der Zuverlässigkeit und Fehlertoleranz. Bei diesem Punkt sollte ein Kompromiss zwischen Fehlertoleranz und Sensorkosten erzielt werden. Außerdem ist Block d.) mit Block c.), also der Kommunikationsschnittstelle, zum Austausch von Daten/Informationen verbunden, wie durch den Doppelpfeil angedeutet. So können über den Block c.) externe Signale, wie beispielsweise die Fahrzeugrohgeschwindigkeit, an Block d.) übermittelt werden sowie nach außen zu versendende gemessene und modellierte Signale von Block d.) an Block c.) weitergeleitet werden. Ferner ist Block d.) mit Block g.), also der Diagnosefunktion, zum Austausch von Daten/Informationen verbunden, wie durch die beiden Pfeile angedeutet. So können gemessene/modellierte Signale vom Block d.) an Block g.) übergeben werden, um eine aktive Diagnose durchzuführen. Außerdem ist Block d.) mit Block e.) zum Austausch von Daten/Informationen verbunden, wie durch den Pfeil/Doppelpfeil angedeutet. So können Freigabeinformationen beziehungsweise Freigabeanforderungen, beispielsweise zur Modelladaption, an den Block e.) übermittelt werden. Darüber hinaus ist Block d.) mit Block f.) zum Austausch von Daten/Informationen verbunden, wie durch den Pfeil angedeutet, wobei Rekonfigurationsinformationen aus dem Block f.) an den Block d.) übermittelt werden können, wobei Block f.) Funktionen zugeordnet sind, die einer „Rekonfiguration”, also einer Umschaltung von Signalen, Strukturen oder Parametern zur Laufzeit entsprechen, die in Abhängigkeit von Diagnose-Ergebnissen erfolgen.
In der erfindungsgemäßen Struktur stellt der Block e.) den Diagnose-Manager dar, dem Funktionen zugeordnet sind, welche die Aufgabe haben, Diagnose-Ergebnisse, die von der Diagnosefunktion gemäß Block g.) bereitgestellt werden, zu verwalten. Die erkannten Fehler werden im nichtflüchtigen Speicher abgelegt und/oder nach außen über einen Diagnosetester über eine Verbindung mit Block c.) weitergeleitet. Ferner sind die Freigabe von Funktionen in Abhängigkeit von den Diagnoseergebnissen, die Verwaltung der Werkstattdiagnosen, die MIL-Verwaltung, die Fehlerheilung sowie die Erfüllung weiterer vom Gesetzgeber abverlangter Anforderungen Aufgaben der Funktionen, die Block e.) zugeordnet sind. Der Block e.) kommuniziert mit den Blöcken a.) bis d.) und f.) bis h.), wie durch die Pfeile beziehungsweise Doppelpfeile angedeutet. Eingangsgrößen von Block e.) sind Anforderungen, beispielsweise nach Freigaben zur Betriebsartenumschaltung, vom Block h.), also dem Controller. Eingangsgrößen von Block e.) sind weiterhin Anforderungen, beispielsweise nach Freigaben zur Modelladaption, vom Block d.), also dem Beobachter. Eingangsgrößen von Block e.) sind außerdem Diagnosestati und -ergebnisse vom Block g.), also der Diagnosefunktion. Eingangsgrößen von Block e.) sind ferner Diagnosestati und -ergebnisse vom Block c.), also der Kommunikations-Schnittstelle. Eingangsgrößen sind außerdem Diagnosestati und -ergebnisse vom Block a.), also der Sensor-Schnittstelle. Eingangsgrößen sind letztendlich auch Diagnosestati und -ergebnisse vom Block b.), also der Aktuator-Schnittstelle. Ausgangsgrößen von Block e.) sind Freigaben an den Block h.), d.) und f.) sowie Freigaben und Sperrungen an den Block g.) sowie Fehlerspeicherinformation an den Block c.).
In der erfindungsgemäßen Struktur stellt der Block f.) den Rekonfigurator dar, dem Funktionen zugeordnet sind, welche die Aufgabe haben, im Fehlerfall eine Rekonfi guration des Blockes d.) und/oder des Blockes h.) vorzunehmen. Unter dem Begriff „Rekonfiguration” wird erfindungsgemäß eine Signal-, Struktur- oder Parameterumschaltung zur Laufzeit verstanden. Die Rekonfiguration erfolgt auf Basis der Diagnose-Ergebnisse. Wenn beispielsweise in einer Diagnosefunktion ein Sensor als fehlerhaft erkannt wird, dann sollen die dem Block f.) zugeordneten Funktionen die notwendigen Signal- und Strukturumschaltungen im Block d.) antriggern. Wird ein Aktuator oder eine andere Systemkomponente als fehlerhaft erkannt, dann sollen sowohl Block d.) als auch Block h.) entsprechend rekonfiguriert werden. Der Block f.) ist zum Austausch von Daten/Informationen mit dem Block e.), dem Block d.) und dem Block h.) verbunden, wie durch die Pfeile beziehungsweise den Doppelpfeil angedeutet. Eingangsgrößen des Blockes f.) sind die vom Block e.) verwalteten Diagnoseinformationen. Ausgangsgrößen des Blockes f.) sind Anforderungen zur Rekonfiguration, die an den Block h.) und/oder den Block d.) gehen. Erfindungsgemäß führt der Einsatz eines Rekonfigurators zu einer Erhöhung der Fehlertoleranz des Gesamtsystems beziehungsweise der Vorrichtung zur Steuerung und Regelung eines Antriebssystems, da im Fehlerfall zur Laufzeit, getriggert durch den Rekonfigurator, von einem Messwert auf einen Modellwert umgeschaltet werden kann.
In der erfindungsgemäßen Struktur stellt der Block g.) eine Diagnosefunktion dar, der wiederum Funktionen zugeordnet sind, welche die Aufgabe haben, eine Diagnose durchführen zu können. So befinden sich in Block g.) signal- und/oder modellbasiert Diagnosefunktionen. Die dazu notwendigen Informationen über Systemzustände und Residuen, die als Grundlage für diese Diagnosefunktionen dienen, werden vom Block d.) bereitgestellt. Die Diagnosefunktionen haben auch die Möglichkeit, die Stellsignale oder Sollwerte im Block h.) zu beeinflussen, um eine aktive Diagnose durchführen zu können. Der Block g.) kommuniziert mit dem Block d.), dem Block e.) und dem Block h.), wie durch die Pfeile beziehungsweise den Doppelpfeil angedeutet. Eingangsgrößen des Blockes g.) sind die gemessenen und modellierten Signale inklusive der Residuen vom Block d.) und die Diagnosefreigabeinformation des Blockes e.). Ausgangsgrößen des Blockes g.) sind Diagnoseergebnisse und Statusinformationen, die an den Block e.) übermittelt werden und Sollwertmanipulationen zur Durchführung aktiver Diagnosen, die an den Block h.) übermittelt werden.
In der erfindungsgemäßen Struktur stellt der Block h.) einen Controller dar, dem wiederum Funktionen zugeordnet sind, welche die Aufgabe haben Sollwerte und Stellsignale zu generieren, strategische Entscheidungen zu treffen und eine Koordination der Komponenten, also Koordination der Funktionen und Module durchzuführen, die zu einer bestimmten Hardwarekomponente, wie dem Frischluft- oder Abgassystem eines Fahrzeuges gehören. Als Grundlage für diese Aufgaben dienen in erster Linie jene Informationen, die aus dem Block d.) empfangen werden. Im Block h.) können folgende Kategorien von Funktionen enthalten sein, wie etwa Reglerfunktionen, Steuerungen, Sollwertgenerierung, Strategische Entscheidung, wie beispielsweise eine Betriebsartenumschaltung oder Koordination von Antriebsstrangkomponenten. Die im Block h.) enthaltenen Funktionen lassen sich ebenso wie die des Blockes d.) den einzelnen Hardwarekomponenten zuordnen. Der Block h.) ist zum Austausch von Daten/Informationen mit den Blöcken b.), c.), d.), e.), f.), g.) und h.) verbunden, wie durch die Pfeile, den Doppelpfeil und den fettgedruckten Pfeil angedeutet. Eingangsgrößen sind Rekonfigurationsinformation vom Block f.), Freigabeinformationen vom Block e.), Sollwertmanipulationen vom Block g.), externe Information, wie beispielsweise Momentensollwerte vom Getriebe, die über den Block c.) eintreffen sowie die gemessenen und/oder modellierten Signale vom Block d.). Ausgangsgrößen sind die Stellsignale, die an den Block b.) und den Block c.) gehen, Adaptionswerte und Informationen über Stellanschläge an den Block g.) sowie Freigabe-Anforderungen an den Block e.).
Zusammengefasst ist die erfindungsgemäße modulare Struktur so allgemein gehalten, dass sie auch für komplexere Antriebssysteme anwendbar bleibt. So lassen sich beispielsweise in Hinblick auf den Betrieb von Kraftfahrzeugen ohne weiteres aktive Bremsen oder auch hybride Antriebskonzepte mit ihren spezifischen Aktuatoren und Systemkomponenten umsetzen. An der Struktur sind hierzu keine Änderungen erforderlich, der Entwicklungsaufwand beschränkt sich einzig auf die den einzelnen Blöcken zugeordneten Funktionen, beispielsweise betreffend das Antriebsmanagement im Block h.). Der Detaillierungsgrad dieser Beschreibung trägt dem Anspruch an die Allgemeingültigkeit Rechnung. So werden keine Beschreibungen von Funktionen, Implementierungsaspekten, Rechenrastern, Betriebszuständen offenbart. Vielmehr sollen der Zweck sowie das prinzipielle Zusammenwirken der im folgenden Abschnitt definierten Struktur-Blöcke a.) bis h.) beschrieben werden. Diese Struktur-Blöcke a.) bis h.) sind die Container für die zu entwickelnden Funktionen und Module. Welche dieser bevorzugt als Software ausgeführten Komponenten im Spezialfall eines bestimmten Antriebes diese Container ausfüllen, ist allein von den technischen Notwendigkeiten abhängig. So soll beispielsweise nur für den Fall, dass im Rahmen einer Anwendung im Bereich von Verbrennungskraftmaschinen eine Sekundärluftpumpe im System vorhanden ist, auch eine entsprechende Diagnosefunktion in den Steuergerätecode eingebunden werden.
Die in 1 dargestellten Blöcke a.) bis h.), welche die Systemarchitektur beschreiben, beinhalten nun eine Vielzahl von Modulen und Funktionen. Diese wiederum arbeiten im allgemeinen mit verschiedenen Zeitrastern. Grundsätzlich sind folgende Rechenraster vorzusehen. Kurbelwinkelsynchrone Raster, wie ein zündsegmentsynchrones Raster einer Verbrennungskraftmaschine und in Bezug auf eine Hochdruckeinspritzpumpe einer Verbrennungskraftmaschine ein förderhubsynchrones Raster. Außerdem sind zweckmäßigerweise zeitsynchrone Raster vorzusehen, beispielsweise 1 ms, 10 ms, 20 ms, 100 ms und so weiter. Denkbar sind ebenfalls ereignisgesteuerte Tasks, wie zum Beispiel das Ausführen der Rekonfiguration nur im Falle eines entsprechenden Fehlers. Es sollte darauf geachtet werden, dass die vom Block a.) eingelesenen Signale angemessen abgetastet werden, so dass kein Aliasing auftritt. Ferner ist zu beachten, dass bei einer Wiederabtastung von Signalen mit einer längeren Abtastzeit Anti-Aliasing-Filter vorzusehen sind, wenn ein signifikanter Energiegehalt oberhalb der Nyquistfrequenz vorhanden ist.
Gemäß 1 umfasst die erfindungsgemäße Struktur außerdem den Block i.), der in einer Bibliothek Klassen von Funktionen enthält, die zur Laufzeit aufgerufen werden. Es kann sich hierbei z. B. um einen Optimierer, einen rekursiven Schätzalgorithmus o. ä. handeln.
Gemäß 1 umfasst die erfindungsgemäße Struktur weiterhin den Block j.), der Kernfunktionalitäten des zu Grunde liegenden Steuergeräts enthält, welche u. a. das Betriebssystem und das Task-Scheduling umfassen.
Gemäß 1 umfasst die erfindungsgemäße Struktur weiterhin den Block k.), der die Schnittstelle zu einem Applikationssystem, also die dafür notwendige Hardware, Kommunikation und Software, darstellt. Dieser Block soll gewährleisten, dass anhand eines PCs über eine Standardschnittstelle die Parameter der Funktionen verstellt und Signale, wie Messwerte und berechnete Signale, aus dem Steuergerät aufgezeichnet werden können.
Abschließend umfasst die erfindungsgemäße Struktur weiterhin den Block l.), der einer nicht weiter beschriebenen Überwachung des Steuergerätes bezüglich unzulässiger Beschleunigung eines zu Grunde liegenden Fahrzeugs dient. Die erfindungsgemäße Architektur sieht die Gruppierung von Funktionen des Blockes h.) und des Blockes d.), soweit möglich auch der weiteren Blöcke, in physikalisch orientierte Module vor. Eine für die verschiedensten Verbrennungsmotoren gleichsam allgemeingültige Unterteilung in Module ist die folgende:

1. Luftsystem (Air System)
2. Kraftstoffsystem (Fuel System)
3. Verbrennungsprozess (Combustion)
4. Abgassystem (Exhaust System)
5. Antriebsstrang (Powertrain)
6. Kühlsystem (Thermal System)
7. Elektrisches System (Electrical System)

Im Zuge einer Erweiterung der jeweiligen Steuergerätesoftware für weitere Antriebskonzepte ist die obige Liste sinngemäß erweiterbar. Die Architektur erlaubt verschiedene Betriebszustände neben dem normalen Betrieb, z. B. die Initialisierung und den Nachlauf. Im Betriebszustand „Initialisierung” werden sämtliche Steuergerätefunktionen initialisiert. Im Betriebszustand „Nachlauf” werden etwaige stationäre Adaptionen ausgeführt, Adaptionswerte in den nichtflüchtigen Speicher geschrieben und so weiter. Die nähere Definition dieser und möglicher weiterer Betriebszustände hängt von den zu entwickelnden Funktionen ab. Da die Architektur im wesentlichen Signalflüsse festlegt, stellt diese auch keinen Widerspruch zu etwaigen weiteren Betriebszuständen dar.
Ausdrücklich nicht Bestandteil der hier beschriebenen Architektur sind folgende Aspekte. Hinsichtlich der Steuergerätehardware ist die Softwarearchitektur unabhängig und soll sich auf verschiedensten Zielplattformen realisieren lassen. Betreffend die Motor- und Triebstranghardware soll die Softwarearchitektur ein breites Spektrum insbesondere von Fahrzeugkonzepten abdecken. Im Zusammenhang mit der Umsetzung der Funktionen kann und soll der Funktionsentwicklung nicht vorgegriffen werden. Die Architekturbeschreibung hat einen allgemeinen Charakter und sollte nicht von der Umsetzung der notwendigen Funktionen abhängig sein, sondern vielmehr alle technisch sinnvollen Realisierungen erlauben.
Gemäß 2 kann die erfindungsgemäße modulare Struktur als Bestandteil einer Vorrichtung zur Steuerung und Regelung eines Antriebssystems auch aus Sicht des Verbundes zur Schaffung offener Standards für Softwarearchitekturen von Kraftfahrzeugen, AUTOSAR, dargestellt werden. Der AUTOSAR-Standard sieht eine Unterteilung der Steuergerätesoftware in die Anwendungsschicht (Application Layer) und die Infrastrukturschicht vor. Diese beiden Schichten tauschen Daten über die sogenannte Laufzeitumgebung (Run Time Environment/RTE) aus. Letztere bildet eine Schnittstelle, die eine Entkopplung der Anwendungssoftware von der Hardware ermöglicht. Auch innerhalb der Anwendungsschicht wird über die RTE kommuniziert. Es gibt sowohl Architektur-Blöcke, deren Inhalt ausschließlich oberhalb der RTE liegt (z. B. der Controller und der Beobachter) als auch Blöcke, welche Anteile oberhalb und unterhalb der RTE enthalten (z. B. die Aktuator-Schnittstelle, die Sensor-Schnittstelle, der Diagnose-Manager, die Bibliothek).
Gemäß 3 ist der Block a.), also die Sensor-Schnittstelle, im Detail dargestellt. Die Sensor-Schnittstelle bildet die hinsichtlich der Sensoren hardwarespezifische Schnittstelle der erfindungsgemäßen Vorrichtung zur Steuerung und Regelung eines Antriebssystems beziehungsweise eines Steuergerätes. In der Sensor-Schnittstelle befinden sich Funktionen für die Grundverarbeitung der an das Steuergerät von den Sensoren gesendeten Sensorrohsignale. Die Sensor-Schnittstelle ist dabei modular aufgebaut, um eine einfache Anpassung der Software an Änderungen der Sensorhardware zu ermöglichen. Eingangssignale der Sensor-Schnittstelle sind die Ausgangssignale der Sensoren. Die Schnittstelle wird durch zwei Schichten strukturiert. Auf unterster Ebene befindet sich die Hardware-Zugriffsschicht (Hardware Access). In dieser befinden sich die hardwarespezifischen Treiber zum Auslesen der Eingangsschnittstellen (Hardware Driver). Diese sind zum Beispiel Treiber für den Zugriff auf Digital- und Analogwandler (ADC) der verwendeten Steuergerätehardware. Zusätzlich werden von der Schicht den Hardware-Zustand betreffende Diagnoseergebnisse (Diagnostic Service) geliefert (Inp-Module beziehungsweise Input-Module), wobei es sich hierbei in der Regel um Statusworte oder binäre Größen handelt. Über der Hardware-Zugriffsschicht befindet sich die Sensorsignal-Umwandlungsschicht (Sensor Conversion). Sie umfasst Sensorfunktionen, die die von der Hardwarezugriffsebene gelieferten Sensorrohdaten in physikalische Sensorwerte umrechnen (Transformation) und eine einfache elektrische Diagnose (Low-Level-Diagnosis, Range Check, Plausibility) durchführen. Die unterste Ebene der Sensor-Schnittstelle ist gemäß AUTOSAR Bestandteil der Basis-Software der ECU. Gedanklich gesehen wird die Hardware-Zugriffsschicht von der Sensor-Umwandlungsschicht durch das Runtime Environment (RTE) getrennt. Die physikalischen Sensorwerte (zusammengefasst im SensorBus) werden an den Beobachter in Block d.) weitergeleitet. Zusätzlich werden die Ergebnisse der in der Sensor-Schnittstelle durchgeführten Diagnosen zusammengefasst im SensorStatusBus an den Block e.), also den Diagnose-Manager, weitergegeben. Diese externen Schnittstellen können im Zuge einer Implementierung, beispielsweise in SIMULINK^®, über Signalbusse realisiert werden.
In der Hardware-Zugriffsschicht erfolgt die Ansteuerung von Hardwarebausteinen für die Signalerfassung (A/D-Wandler, Digital-I/Os). Die vom Hardware-Treiber gelieferten Spannungswerte werden von den in der Sensor-Umwandlungsschicht enthaltenen Umwandlungsfunktionen weiterverarbeitet. Dabei erfolgt die Umrechnung der elektrischen Signale in physikalische Größen wie Druck oder Temperatur. Die Sensorwerte werden von der Sensor-Schnittstelle in dem funktionsseitig erforderlichen kleinsten Zeitraster an den Beobachter, also an Block d.), weitergegeben. Zusätzliche Aufgabe der Sensor-Umwandlungsschicht ist die Durchführung hardwarenaher Grunddiagnosen und gegebenenfalls die Durchführung einer Signalplausibilisierung. Die Diagnose umfasst dabei einfache elektrische Diagnosen (Signal-Range-Check der eingehenden Sensorspannungen). Plausibilisierungen werden nur dann in der Sensor-Schnittstelle durchgeführt, wenn für einen Messwert redundante Sensorinformationen zur Verfügung stehen, wie z. B. für den Drosselklappenöffnungswinkel durch zwei Lagesensoren. Da diese Funktionen hardwarenah liegen, sollen sie als Hardware-Abstraktions-Schicht dienen. Wenn ein Sensor S der Firma ABC mit einem anderen Sensor S der Firma XYZ umgetauscht wird, dann soll nur die Sensor-Schnittstellen-Funktion S davon beeinflusst sein. Daher sollten zwischen Umwandlungsroutinen, die sich auf einer Ebene des Sensor-Interface befinden, keine Querkopplungen existieren.
Gemäß 4 ist weiterhin eine prinzipielle Darstellung des Signalflusses vom gewandelten Sensorspannungswert, der vom ADC geliefert wird, bis zum Istwert (Actual Value) aufgeführt, der dann von der Funktionssoftware verwendet beziehungsweise Block b.) und/oder Block h.) zugeführt wird. Nach Verarbeitung des Sensorsignals durch die Sensor-Schnittstelle wird der physikalische Sensor-Istwert an den Beobachter in Block d.) weitergegeben. Im Beobachter kann eine Korrektur des Wertes unter Verwendung einer geeigneten Adaptionsstrategie erfolgen. Der Sensorwert wird dann an einen Auswahlblock weitergegeben, mit dem zwischen dem Ersatzwert (Backup Value), einem modellierten (Model Value), dem gemessenen (Correction) und einem zusätzlich gefilterten Sensorwert (Filter) umgeschaltet werden kann. Die Ergebnisse der Hardware-Diagnose und Low-Level-Diagnose der Sensor-Schnittstelle werden an den Diagnose-Manager beziehungsweise Block e.) weitergegeben. Weiterhin erhält der Diagnose-Manager die Ergebnisse der aus den Beobachterresiduen (Model Value minus Actual Value) berechneten Diagnosen in Block g.). Mit Hilfe einer Entscheidungsstrategie wird dann über den Rekonfigurator in Block f.) gegebenenfalls eine Umschaltung auf einen Ersatz- oder Modellwert im Beobachter durchgeführt. Ein Merkmal der Sensor-Schnittstelle ist es, dass für jeden gewandelten Sensorrohwert eine Umwandlungsroutine zur Berechnung des physikalischen Sensormesswerts zur Verfügung steht. Ein weiteres Merkmal der Sensor-Schnittstelle ist es, dass für jeden analogen Sensorwert eine elektrische Diagnose durchgeführt werden kann. Ein noch weiteres Merkmal der Sensor-Schnittstelle ist es, dass die Weitergabe der Sensorwerte in dem funktionsseitig erforderlichen kleinsten Zeitraster erfolgen kann, wobei die Erhöhung der Zeitauflösung eine funktionsseitige Anforderung erfordert. Ein noch weiteres Merkmal der Sensor-Schnittstelle ist es, dass eine Signalfilterung dann in der Sensor-Schnittstelle durchgeführt werden kann, wenn ausschließlich ein gefilterter Wert von allen Funktionen benötigt wird, die diesen Wert im kleinsten Zeitraster verwenden. Mit anderen Worten wird die Filterung nur dann in der Sensor-Schnittstelle durchgeführt, wenn im System von keiner Funktion der Sensorwert im kleinsten Zeitraster als ungefiltertes Signal benötigt wird. Ein noch weiteres Merkmal der Sensor-Schnittstelle ist es, dass wenn für die Erfassung eines physikalischen Signals zwei Sensoren gleicher Art vorhanden sind, wie beispielsweise zwei Lagesensoren des Fahrpedals eines Kraftfahrzeuges, dann soll die entsprechende Umwandlungsroutine, wenn möglich, die redundanten Signale gegenseitig plausibilisieren und einen einzigen physikalischen Wert bereitstellen. Ein noch weiteres Merkmal der Sensor-Schnittstelle ist es, dass zwischen den Umwandlungsroutinen der Sensor-Schnittstelle keine Querkopplungen zugelassen sind, also beispielsweise Verwendung des Drehzahlsignals für die Umwandlungsroutine des Ladedrucksensors. Dadurch soll die einfache Austauschbarkeit von Sensoren unterstützt werden.
Die Schnittstellen innerhalb des Blockes a.) sind wie folgt charakterisiert. Bei der Kommunikation der Schichten werden die Signale gruppiert und beispielsweise über Busse zwischen den Blöcken versendet, also eine Kommunikation zwischen den Schichten der Sensorschnittstelle erfolgt beispielsweise bei einer Implementierung in SIMULINK^® über Busse, welche eine übersichtliche Signalgruppierung ermöglichen. Unbenommen bleibt hierbei die Möglichkeit, andere Implementierungswerkzeuge wie beispielsweise ASCET^® zu verwenden. In diesem Fall kann die Signalgruppierung über die Verwendung entsprechender Bezeichner für die Signale erfolgen, die erforderlichenfalls als Messages zu deklarieren sind. Die vom Hardware-Treiber zur Verfügung gestellten Eingangssignale werden in Busse gruppiert und an die Umwandlungsschicht weitergegeben. So werden analoge Sensorsignale in einen Bus gruppiert. Auch digitale Sensorsignale, wie beispielsweise Bitgrößen, Tastverhältnisse, Frequenzen, Periodendauern werden in einen Bus gruppiert. Darüber hinaus werden winkelbezogene Sensoreingangssignale der Kurbel- und Nockenwelle in einen Bus gruppiert. Die Diagnoseergebnisse der Hardware-Zugriffsschicht werden zusammengefasst in einem Bus und an höhere Schichten weitergegeben.
Die innerhalb des Blockes a.) zu realisierenden Funktionen lassen sich wie folgt charakterisieren. Die Sensor-Schnittstelle umfasst Umwandlungsroutinen für folgende Sensor-Signaltypen: für analoge Sensorsignale, wie beispielsweise von einem Temperatur- oder Drucksensor, für spezielle analoge Sensorsignale, wie beispielsweise von einem Klopfsensor oder einer Lambdasonde, für Schalter, wie zum Beispiel einen Türkontaktschalter, für Drehzahl-Sensorsignale, beispielsweise von einem Induk tiv- oder Hallgeber, für pulsweitenmodulierte digitale Sensorsignale, wie zum Beispiel von einem HFM-Sensor, für spezielle digitale Sensorsignale, wie zum Beispiel von einem Ölfüllstands und -temperatursensor. Im Falle von Umwandlungsroutinen für analoge Sensorsignale und auch spezielle analoge Sensorsignale und periodische, digitale Sensorsignale wird eine Low-Level-Diagnose mit Überprüfung der Bereichsgrenzen des Sensorsignals durchgeführt. Bei Messgrößen, die von zwei Sensoren gleicher Art aufgenommen werden, beispielsweise Drosselklappenlagesensoren oder Fahrpedallagesensoren wird eine gegenseitige Plausibilisierung der Signale durchgeführt und eines der Signale im SensorBus zum Beobachter in Block d.) weitergeleitet. In der Hardwarezugriffs-Schicht sind hardwarespezifische Routinen und Treiber zum Zugriff auf Eingangsmodule der Hardware und das Auslesen von hardwarenahen Statusinformationen angesiedelt. Die Funktionen besitzen eine hohe Hardwareabhängigkeit. Sie ermöglichen den Zugriff auf analoge und digitale Eingangsmodule und spezielle Eingangsmodule, wie zum Beispiel zur Auswertung von Klopf- und Lambdasondensignalen. Die Auswertung eines Temperatursensors in der Sensor-Schnittstelle soll die Verarbeitung eines Sensorsignals beispielhaft verdeutlichen. Das analoge Spannungssignal des Sensors wird dabei von der Hardwarezugriffs-Schicht an die Umwandlungsroutine weitergegeben. Zusätzlich werden Statusinformationen über den Zustand des A/D-Wandlers und der Hardware weitergegeben. Die Berechnung eines Temperaturwertes erfolgt dann beispielsweise über ein Kennlinie aus dem ausgelesenen Spannungswert. In der Umwandlungsroutine erfolgt zusätzlich eine Abprüfung des Signalbereichs mit Rückgabe des Diagnoseergebnisses. Die Statusinformationen werden im SensorStatusBus und der gemessene Temperaturwert im SensorBus weitergegeben.
Gemäß 5 ist der Block b.), also die Aktuator-Schnittstelle, im Detail dargestellt. Die Aktuator-Schnittstelle beinhaltet zum einen Funktionen, die für die Aufbereitung von Stellsignalen zuständig sind und diese als Eingangssignale den Endstufen-Treibern zur Verfügung stellen. Zum anderen beinhaltet die Aktuator-Schnittstelle auch Hardware-spezifische Funktionen, die zusätzliche für die Ansteuerung von Endstufen notwendige Treibersignale generieren, wie zum Beispiel die Ladezeit von Zündspulen einer Verbrennungskraftmaschine. Die Aktuator-Schnittstelle besteht prinzipiell aus zwei hardware-spezifischen Ebenen. In einer Ebene werden die aus Block h.), also dem Controller, über den ControlBus kommenden Stellsignale in Ein gangssignale für die hardwarenahen Treiber umgewandelt, dabei handelt es sich quasi um die Signalaufbereitungsebene. Diese Ebene wird analog zu Block d.) und dem Block h.) in folgende Hierarchien gegliedert: Air System, Fuel System, Powertrain, Thermal System, Exhaust System und Combustion System. Die zweite Ebene der Aktuator-Schnittstelle ist die Treiber-Ebene als Schnittstelle zu den peripher angeschlossenen Endstufen. Sie ist nach AUTOSAR Bestandteil der Basis-Software der ECU. Gedanklich gesehen werden die beiden Ebenen durch die Runtime Enviroment (RTE) getrennt. Als Schnittstelle zwischen der Aktuator-Schnittstelle und anderen Blöcken der AUTOSAR-Anwendungsschicht sind Busse definiert. Die Eingangsgrößen der Aktuator-Schnittstelle sind der ControlBus und der SystemBus. Aus der Aktuator-Schnittstelle herausgeführt wird der ActuatorStatusBus. Der ControlBus, der im Block h.) generiert wird, beinhaltet alle physikalischen und logischen Stellsignale sämtlicher Regler und Steuerungen. Dazu zählen auch Bits für die Aktivierung der Endstufen. Der SystemBus, der im Block d.) zusammengesetzt wird, setzt sich aus den gemessenen und/oder modellierten Signalen beziehungsweise Istwerten zusammen. Der ActuatorStatusBus beinhaltet die Statussignale aller Endstufen, die als Ausgangssignale von Endstufendiagnose-Funktionen zur Verfügung gestellt werden sowie die Status-Bits, die im Rahmen einer Wertebereichsüberprüfung nach einer Signalaufbereitung erzeugt werden. Zu den Statussignalen der Endstufen zählen Signale, die beispielsweise Informationen über Kurzschlüsse nach Masse oder nach Plus der einzelnen Ausgänge der Endstufe wiedergeben. Die in der Aktuator-Schnittstelle zum ActuatorStatusBus zusammengefassten Statussignale werden dem Diagnose-Manager in Block e.) zur weiteren Verarbeitung zur Verfügung gestellt. Sofern es erforderlich ist, kann in der Aktuator-Schnittstelle vor dem Zusammenbau des ActuatorStatusBusses zunächst eine Umwandlung der einzelnen vom Systemhersteller abhängigen Diagnose-Signale in ein vom Diagnose-Manager in Block e.) vorgegebenes Format durchgeführt werden beziehungsweise wird vom Systemhersteller keine Schnittstelle für die Diagnose der Leistungsendstufen bereitgestellt, so wird anstelle dessen ein zuvor definiertes Ersatzsignal an dieser Stelle generiert und des weiteren verwendet. Für die Umsetzung der hier genannten Datenbusse bieten sich beispielsweise in SIMULINK^® so genannte Bus-Objekte an, um so der Forderung nach Datenkonsistenz in geeigneter Weise nachzukommen.
Die Signalaufbereitung wandelt die physikalischen Stellsignale gegebenenfalls unter Zuhilfenahme weiterer Informationen in Eingangssignale für die Endstufen-Treiber um. Je nach angeschlossener Aktuatorik gibt es für jeden Steller eine Software-Komponente für die Signalumwandlung. Bei Austausch eines Aktuators A der Firma ABC gegen einen anderen der Firma XYZ sind entsprechend auch die Software-Komponente für die Signalaufbereitung sowie der dazugehörige Treiber für den zu ersetzenden Steller vom Austausch betroffen und anzupassen. Demzufolge sind Querverkopplungen unter den einzelnen Funktionen innerhalb der Signalaufbereitungs- bzw. der Treiberebene nicht zulässig, so dass beim Austausch/Wegfall von Aktuatoren die Schnittstellen anderer Software-Funktionen nicht angepasst werden müssen. Entfällt dagegen ein Aktuator xyz, so entfallen auch die dazugehörige Software-Komponente zur Umwandlung des physikalischen Stellsignals und der Endstufen-Treiber für diesen Aktuator xyz. In diesem Fall müssen die dazugehörigen Software-Funktionen in Block h.) und gegebenenfalls in Block d.) angepasst werden. Entsprechend verhält es sich, wenn ein Aktuator hinzukommt. Für die Ansteuerung des weiteren/neuen Aktuators müssen in der Aktuator-Schnittstelle eine entsprechende Software-Komponente für die Signalaufbereitung und eine Treiber-Komponente für die Ansteuerung der dazugehörigen Endstufe hinzugefügt werden. Der Block h.), also der Controller, ist dahingehend anzupassen, dass für diesen hinzugekommenen Aktuator auch eine entsprechende Stellgröße erzeugt wird.
Die Schnittstellen innerhalb des Blockes b.) sind wie folgt charakterisiert. Sofern von den jeweiligen Software-Funktionen aus der Signalaufbereitungsebene nur einzelne Treibersignale an die dazugehörigen Treiber übergeben werden, dienen ausschließlich Signale als Schnittstellen. Vor einem Aufruf einer Software-Komponente zur Aufbereitung eines physikalischen Signals sind also zunächst das zu konvertierende Stellsignal aus dem ControlBus und die für die Umwandlung und gegebenenfalls einer weiteren Signalverarbeitung (Skalierung) benötigten Signale aus dem SystemBus zu selektieren. Das als Resultat der Signalaufbereitung zur Verfügung stehende Ausgangssignal wird dem entsprechenden Endstufen-Treiber aus der Treiber-Ebene unmittelbar zur weiteren Verarbeitung bereitgestellt. Müssen dagegen mehrere Signale an einen Endstufen-Treiber übergeben werden, so sind diese Signale noch innerhalb der Signalaufbereitungsebene als Bus zusammenzufügen und dem Endstufen-Treiber als Bus zu übergeben. Somit ist auch eine konsistente Datenübergabe gewährleistet, selbst wenn die Signalaufbereitung und der Endstufen-Treiber in unterschiedlichen Tasks aufgerufen werden.
Die innerhalb des Blockes b.) zu realisierenden Funktionen lassen sich wie folgt charakterisieren. Dazu ist in der 6 die Signalaufbereitung exemplarisch für den Aktuator xyz illustriert. Unmittelbar vor dem Aufruf der dazugehörigen Software-Komponente zur Signalaufbereitung wird zunächst das gewünschte Stellsignal und, sofern vorhanden, ein Enable-Bit zur Aktivierung der dazugehörigen Endstufe aus dem ControlBus selektiert. Sofern weitere Informationen, wie beispielsweise die Drehzahl oder die Batteriespannung, für die Aufbereitung notwendig sind, sind diese vom SystemBus zur Verfügung zu stellen. Die ausgewählten Signale werden daraufhin der jeweiligen Software-Komponente übergeben. Sofern die Ansteuerung über den Controller freigegeben wurde (Enable-Bit auf TRUE gesetzt), erfolgt unter Berücksichtigung der physikalischen Dimension die Signalaufbereitung durch eine im allgemeinen nichtlineare mathematische Verknüpfung der selektierten Signale. Das aufbereitete Signal wird anschließend auf seinen Wertebereich überprüft, wobei der minimal (y_min) und der maximal zulässige Wert (y_max) von der anzusteuernden Aktuatorik abhängen und beide Werte einstellbar sind. Im Fall einer Unter- bzw. Überschreitung des zulässigen Wertes wird ein Status-Bit gesetzt und das aufbereitete Signal entsprechend nach y_min beziehungsweise y_max begrenzt. Ist dagegen die Ansteuerung des Stellers nicht freigegeben worden, so ist abhängig vom Treiber eine Signalaufbereitung entweder nicht erforderlich oder das aufzubereitende Signal ist auf einen speziellen Wert zu setzen (z. B. Ladezeit der Zündspulen = 0 s wenn nicht gezündet werden soll). Die Treibereingangssignale und das auf FALSE gesetzte Enable-Bit werden als Bus unmittelbar an den Endstufen-Treiber übergeben. Sofern es erforderlich ist, kann in jeder Software-Komponente zur Signalaufbereitung auch eine Umwandlung des Enable-Bits in ein vom Systemhersteller vorgegebenes Format durchgeführt werden beziehungsweise wird vom Systemhersteller keine Schnittstelle für die Aktivierung einzelner Leistungsendstufen bereitgestellt, so wird das Enable-Bit für diese Endstufen nicht an die Treiber-Ebene weitergeleitet. Anhand eines Beispiels wird nun die Signalaufbereitung demonstriert. Der Raildruckregler als Bestandteil des Blockes h.), also dem Controller, berechnet in Abhängigkeit der jeweils vorherrschenden Betriebsbedingung eine zu fördernde Kraftstoffmenge in beispielsweise Liter pro Stunde. Diese wird in der Aktuator-Schnittstelle unter Zunahme weite rer zum Teil Hardware-spezifischer Informationen, wie der Anzahl und Kontur der Nocken, der Induktivität von Spulen, der Batteriespannung, zunächst in einen Winkelbereich und unter Verwendung der Motordrehzahl in eine Zeitdauer umgerechnet. Beginn der Ansteuerung in Form eines Winkels und die Zeitdauer der Ansteuerung sind die aus der Aktuator-Schnittstelle kommenden Eingangsgrößen des Endstufen-Treibers, die damit das Timing für die Ansteuerung des Mengensteuerventils festlegen. Über- bzw. unterschreiten Winkel und Zeitdauer ihre jeweiligen minimal und maximal zulässigen Werte, so werden die entsprechenden Status-Bits gesetzt und die Werte entsprechend begrenzt. Das Signal zur Ansteuerung der Endstufe wird schließlich durch den Endstufen-Treiber als Teil des Complex Drivers aus der Treiber-Ebene generiert. Ändert sich beispielsweise im Laufe des Einsatzes die Ventilcharakteristik des Mengensteuerventils und kann diese unter Zuhilfenahme weiterer Größen aus dem SystemBus quantitativ beschrieben werden, so ist mit der vorliegenden Architektur im Rahmen der Signalaufbereitung der Aktuator-Schnittstelle ein korrigierender Eingriff möglich. Die gestrichelt gezeichneten Linien für die selektierten Signale aus dem ControlBus und SystemBus sollen andeuten, dass die Generierung der Eingangssignale für die einzelnen Endstufen-Treiber zum Teil auch ohne Informationen aus dem SystemBus beziehungsweise einzelne Treibereingänge ausschließlich aus Signalen aus dem SystemBus erzeugt werden können, wie beispielsweise die Ladezeit der Zündspulen.
Der Block d.), also der Beobachter/die Signalverarbeitung, wird an dieser Stelle im Detail beschrieben. Die Funktionen dieses Blocks haben die Aufgabe, den momentanen Ist-Zustand des zu steuernden und zu regelnden Systems, insbesondere einen Verbrennungsmotor in einem Kraftfahrzeug, zu beobachten. Diese Beobachtung findet modellgestützt statt. Vereinfachte nichtlineare dynamische Modelle werden eingesetzt, um anhand der Stellsignale und der Umweltbedingungen die messbaren und nichtmessbaren Zustandsgrößen des Systems zu schätzen. Modellierte messbare Zustände werden mit Messsignalen verglichen und daraus Residuen generiert. Anhand dieser Residuen wird eine Beobachterrückführung realisiert, um die modellierten Zustandsgrößen zu korrigieren. Das Prinzip eines Zustandsbeobachters ist in der 7 dargestellt. Als Zustandsbeobachter realisiert der Beobachter/die Signalverarbeitung gemäß Block d.) folgende Funktionen. Auf der einen Seite ist das die Beobachtung der Systemzustände, wobei diese beobachteten Zustände einerseits ver wendet werden können, um nicht messbare Größen zur Steuerung und Regelung einzusetzen. Auf der anderen Seite können im Fehlerfall die beobachteten Zustände als Ersatzwerte für die Messsignale verwendet werden. Die Beobachter-Funktionen sollen die Funktionen des Blockes h.), also des Controllers, und des Blockes g.), also der Diagnosefunktion, mit der Information über den aktuellen Systemzustand und mit Residuen versorgen. Soweit möglich, soll der Block d.), also der Beobachter, gewährleisten, dass die Funktionen des Blockes h.) unabhängig von der Sensorkonfiguration realisiert werden können. Außerdem soll der Beobachter/die Signalverarbeitung gemäß Block d.) modell- oder signalbasierte Sensoradaptionsverfahren realisieren, welche den Einfluss der Messgenauigkeit der Sensoren reduzieren.
Der Block d.) stellt also nicht nur einen Zustandsbeobachter dar, sondern enthält auch weitere Funktionen zur Signalverarbeitung. Besonders hervorzuheben ist an dieser Stelle die Sensoradaption, anhand derer der Einfluss der Sensorungenauigkeiten reduziert werden soll. Um eine Sensoradaption oder -korrektur durchführen zu können, werden Informationen von anderen Sensoren und Modellen benötigt. Da diese Informationen in Block d.) vorhanden sind, findet die Sensorkorrektur und -adaption auch dort statt.
Gemäß 8 werden die Funktionen des Beobachters für das Gesamtsystem in die folgenden drei Ebenen gruppiert. „Model Layer” (Modellebene), „Observer Feedback” Layer (Beobachterrückführungsebene/Rückführebene) und „Sensor Adaptation and Correction Layer” (Sensoradaptions- und -korrekturebene). Im folgenden werden die oben vorgestellten drei Ebenen näher beschrieben.
Hinsichtlich des Funktionsprinzips eines Beobachters ist das Zusammenspiel aus vorwärtsgerichteten Prozessmodellen, die in der Ebene „Model Layer” angeordnet sind und der Beobachterrückführung, welche sich in der Ebene „Observer Feedback Layer” befindet, von essentieller Bedeutung. Die Rückführung sorgt dafür, dass die von den Modellen berechneten Prozesszustände, wie Drücke, Drehzahlen, Temperaturen, dynamisch mit den tatsächlichen Werten übereinstimmen. Die Rückführung ist frei parametrierbar, insbesondere kann sie auch so strukturiert werden, dass Rückwirkungen, d. h. Korrekturen, auf bestimmte Teilsysteme beschränkt bleiben. Auf diese Weise kann das Problem des Entwurfs eines „großen” Beobachters, der alle Informationen verwendet, auf das wesentlich leichter zu lösende Problem des Entwurfs kleinerer Beobachter für einzelne Teilmodelle reduziert werden. Anders formuliert, man kann die Rückführung so gestalten, dass beispielsweise der Antriebsstrang eines Kraftfahrzeuges zur Korrektur des Luftpfades der verwendeten Verbrennungskraftmaschine verwendet wird, da beide über die Drehzahl gekoppelt sind, und umgekehrt. Alternativ kann man die Rückführung auch so parametrieren, dass der Luftpfad nur anhand der Informationen des Luftpfades und der Antriebsstrang nur anhand der Informationen des Antriebsstranges korrigiert wird, d. h. die Information bleibt lokal auf die Module beschränkt. In vielen Fällen ist es möglich, die Zustandsgrößen aus verschiedenen Messgrößen zu rekonstruieren, d. h. das System bleibt für verschiedene Sensorkonfigurationen beobachtbar. Fällt beispielsweise im laufenden Betrieb ein Sensor aus und wird dieses detektiert, so können trotzdem noch, unter Verwendung einer alternativen Beobachterrückführung, die Zustandsgrößen beobachtet werden. Eine zuvor gemessene Größe kann auf diese Weise durch eine rekonstruierte Größe ersetzt werden. Dieser Vorgang wird in der Ebene „Observer Feedback Layer” durch die „Compare and Select”-(CnS-)Funktionen realisiert. Der Block d.) nimmt ferner Funktionen wahr, die über die Beobachtung des Systemzustandes hinausgehen. Die Ebene „Sensor Adaptation and Correction Layer” enthält Funktionen zur Korrektur und Adaption der Sensoren, wie später beschrieben wird.
Die Kommunikation der Ebenen innerhalb des Blockes d.) ist in 9 dargestellt. Eingangsgrößen/-signale der Modellebene sind der SensorCBus, der ControlBus und der OfbBus beziehungsweise die in diesen Bussen enthaltenen Signale. Der SensorCBus enthält die korrigierten und adaptierten Sensorsignale aus der Sensorkorrekturebene. Der ControlBus enthält die vom Block h.) generierten Stellsignale. Der OfbBus enthält die Korrektur aus der Beobachterrückführebene. Ausgangsgröße der Modellebene ist der ModelBus, der sämtliche modellierten (geschätzten) Signale enthält. Eingangsgrößen/-signale der Sensorkorrekturebene sind der SensorBus, der ResidueBus, der OfbBus und der ModelBus beziehungsweise die in diesen Bussen enthaltenen Signale. Der SensorBus enthält die Sensordaten/-signale aus der Sensor-Schnittstelle, also Block a.). Der ResidueBus enthält die berechneten Residuensignale aus der Rückführebene (CnS-Funktionen). Der OfbBus enthält die Korrektur aus der Beobachterrückführebene. Der ModelBus enthält sämtliche modellierten (geschätzten) Signale aus der Modellebene. Die Sensorkorrekturebene wertet die in den genannten Bussen enthaltenen Signale aus, so dass die Ausgangsgröße der Sensorkorrekturebene die korrigierten Sensorsignale sind, die in dem SensorCBus enthalten sind. Eingangsgrößen der Rückführebene sind der ModelBus, der SensorCBus und der ReconfigBus beziehungsweise die in diesen Bussen enthaltenen Signale. Der ModelBus enthält sämtliche modellierten (geschätzten) Signale aus der Modellebene. Der SensorCBus enthält die korrigierten und adaptierten Sensorsignale aus der Sensorkorrekturebene. Der ReconfigBus enthält Rekonfigurationsinformationen aus dem Rekonfigurator, also Block f.). Die Beobachterrückführungsebene wertet die in den genannten Bussen enthaltenen Signale aus, so dass die Ausgangsgröße der Beobachterrückführungsebene der OfbBus, der ResidueBus und der SystemBus, beziehungsweise die darin enthaltenen Signale sind. Der SystemBus enthält die in den „Compare and Select”-(CnS)-Funktionen ausgewählten Sensorgrößen und Modellgrößen, die den aktuellen Zustand des Motors/Fahrzeuges beschreiben.
In 9 nicht dargestellt sind die vom Controller, also Block h.), über die Kommunikationsschnittstelle, also Block c.), versandten Signale. Diese werden genauso behandelt wie der ControllerBus, da es sich hierbei um nichts anderes als Stellsignale handelt, die nicht über die Aktuator-Schnittstelle in Block b.) ausgegeben werden.
Innerhalb des Blockes d.) sind folgende Funktionen zu realisieren. Die Modellebene enthält Prozessmodelle von Motor und Antriebsstrang. Diese Prozessmodelle sind in Module gruppiert, die wie folgt für eine modellhafte Beschreibung einer Verbrennungskraftmaschine in Verbindung mit 8 dargestellt werden. Das Modul ”Air System Model” (AirSysMdl) enthält ein Modell des ansaugseitigen Luftsystems einer Verbrennungskraftmaschine. Dazu zählt auch das als Füllungserfassung bekannte Ladungswechselmodell. Modelliert werden Größen wie Drücke, Temperaturen, Füllung (Frischluft und gegebenenfalls Restgas). Je nach Fahrzeug muss dieses Modell angepasst, also konfiguriert werden. Varianten hierbei sind beispielsweise eine freisaugende oder aufgeladene Verbrennungskraftmaschine mit oder ohne externer Abgasrückführung.
Das Modul Fuel System Model (FuSysMdl) enthält ein Modell des Kraftstoffsystems einer Verbrennungskraftmaschine, bestehend aus Nieder- und Hochdruckseite. Es umfasst u. a. die Komponenten Tank, Kraftstoffförderpumpe, Aktivkohlebehälter (Tankentlüftung), Hochdruckpumpe, Rail und Einspritzventile. Modelliert werden da bei Größen wie Drücke, Temperaturen, Kraftstoffmassenstrom aus Tankentlüftung. Je nach Fahrzeug muss das Modell systemspezifisch angepasst werden. Varianten hierbei sind beispielsweise eine Verbrennungskraftmaschine mit Saugrohr- oder Direkteinspritzung oder der Typ der verwendeten Hochdruckkraftstoffpumpe.
Das Modul „Combustion Model” (CmbMdl) enthält ein thermodynamisches Modell, welches die Energie im Brennraum bilanziert. Modelliert werden sollen die mechanische Energie beziehungsweise das Drehmoment, der Wärmefluss über die Zylinderwände beziehungsweise die Kopplung zum Kühlsystem, der Energiestrom in den Abgasstrang (gegebenenfalls die einzelnen Spezies), das Brennraumlambda, die Verbrennungsschwerpunktlage. Die Auswahl der zu modellierenden Größen hängt ebenfalls von dem Betriebsverfahren der zu Grunde liegenden Verbrennungskraftmaschine ab, also ob es sich beispielsweise um ein Otto-, Diesel- oder Otto-Selbstzündungs-Verfahren handelt.
Das Modul „Exhaust System Model” (ExSysMdl) enthält ein Modell des Abgassystems einer Verbrennungskraftmaschine vom Auslassventil bis zum Auspuff. Es beschreibt die Dynamik von Druck und Temperatur sowie das Abgaslambda. Die Konfiguration des Modells erfolgt abhängig davon, ob es sich um eine Verbrennungskraftmaschine mit oder ohne Abgasturbolader handelt oder abhängig von der Anzahl und Art der Katalysatoren.
Das Modul ”Powertrain Model” (PtMdl) enthält ein Antriebsstrangmodell, welches Größen liefert, wie beispielsweise Drehzahlen, Fahrzeuglängsgeschwindigkeit, Längsbeschleunigung, Torsionswinkel, übertragbares Kupplungsmoment, Fahrwiderstände oder Steigungswinkel. Je nach Fahrzeug muss dieses Modell angepasst werden. Varianten sind hierbei, ob es sich beispielsweise um ein Antriebskonzept mit einem manuell betätigten Wechselgetriebe, einem automatischen Getriebe oder um einen Parallelhybrid, also eine Kombination aus Verbrennungskraftmaschine und elektrischer Maschine, handelt.
Das Modul ”Thermal System Model” (ThSysMdl) enthält ein Modell des Kühlsystems. Es beschreibt die Temperaturen der verschiedenen Kühlkreisläufe und ist ebenfalls je nach Antriebskonzept zu konfigurieren.
Das Modul ”Electrical System Model” (ElSysMdl) enthält ein Modell des elektrischen Systems eines Antriebskonzeptes. Es kann sich hier beispielsweise um ein einfaches Batteriemodell handeln oder auch, im Falle eines Hybridantriebes, um ein komplexes Modell der Leistungselektronik und der elektrischen Antriebe.
In der Beobachterrückführungsebene/Rückführebene existiert zu jeder Hardwarekomponente ein Modul, in dem zwei Funktionen untergebracht sind. Diese realisieren die Berechnung der Beobachterrückführung (Ofb-Funktionen) und die Berechnung der Residuen inklusive der Auswahl der in den SystemBus geschriebenen Signale (CnS-Funktionen). Die Beobachterrückführung bestimmt aus den Residuen einen Korrekturwert. Es wird der gesamte Residuen-Bus verwendet, d. h. prinzipiell können alle Residuen aller Modelle für die Berechnung des Korrekturwertes herangezogen werden.
Der für ein Komponentenmodell berechnete Korrekturwert wird entsprechend der in Verbindung mit 9 beschriebenen Kommunikationsweise in das betreffende Modell eingespeist und dient dort der Korrektur des geschätzten Zustandes. In den CnS-Funktionen wird eine Signalauswahl getroffen. Beispielhaft ist diese Signalauswahl in 10 dargestellt, wobei zwischen einem modellierten Wert/Sensorsignal CR_pMdl, einem gemessenen Wert CR_pMesC, gemessenen und gefilterten Wert CR_pFlt und einem Ersatzwert CR_pSub_C ausgewählt wird. Die Auswahl erfolgt über eine aus dem Rekonfigurationsbus ausgelesene Statusvariable hier CR_stRec. Zudem wird das zu dem jeweiligen Messsignal CR_pMesC gehörende Residuum CR_pResi als Abweichung zwischen Messwert CR_pMesC und Modellwert CR_pMdl berechnet.
In der Sensorkorrektur- und Adaptionsebene (Sensor Correction and Adaptation Layer) werden Funktionen realisiert, die beispielsweise auf der Grundlage eines stationären, von Null verschiedenen Residuums eine Sensorkorrektur vornehmen. Ein Beispiel hierfür könnte die Adaption eines Drucksensors sein, wobei durch einen Adaptionsalgorithmus ein Druckoffset ermittelt wird, welcher dann im nichtflüchtigen Speicher abgelegt wird. Das Verrechnen des Sensorwertes mit diesem Adaptionswert wird dann als Sensorkorrektur bezeichnet.
Gemäß 11 ist der Umfang des Blockes e.), also des Diagnose-Managers, dargestellt. Der Diagnose-Manager ist ein zentrales Verwaltungsorgan der zu dem jeweiligen Antriebskonzept zu Grunde liegenden Vorrichtung zur Steuerung und Regelung beziehungsweise des jeweiligen Steuergerätes. Der Block e.) beinhaltet alle Module und in deren Obhut alle Funktionen, die zur zentralen Organisation und Koordination der Systemabläufe erforderlich sind oder zur zentralen Erfassung und Abbildung des Systemzustandes dienen. Seine Aufgaben bestehen in der zentralen Erfassung, Verwaltung und Steuerung interner Abläufe im Steuergerät sowie der Bereitstellung von Informationen für die Kommunikations-Schnittstelle. Der Block e.) besteht aus den Modulen „Diagnostic Manager” (einschließlich Fehlerspeicher), „Coordination Manager”, ”Symptom Manager”, ”Statistic-Tools”, ”Production/End of Line/Garage” und „System Manager”.
Im Diagnose-Manager werden alle Informationen über den Betriebsablauf und den Systemzustand zentral zusammengetragen, analysiert und abgebildet. Die Auswertung dieser Informationen findet zentral statt und wird zur Planung der weiteren Systemabläufe herangezogen. In diesem Zusammenhang kommt dem Modul „Coordination Manager” als Koordinator der internen Systemabläufe eine zentrale Bedeutung zu. Für die Erfüllung der gesetzlichen Bestimmungen und insbesondere der Anforderungen aus dem Bereich der On-Board Diagnose (OBD) spielen die Module „Symptom Manager”, „Diagnostic Manager” und „Statistic-Tools” eine wichtige Rolle. Zur Bedienung von Forderungen aus den Bereichen Produktion, Bandende und Werkstatt ist ein separater Platzhalter („Production/End of Line/Garage”) vorgesehen. Das Modul „System Manager” dient als Container für alle anderen, auch systemübergreifenden Funktionalitäten, die einen Bezug zum Motorsteuergerät haben oder benötigen.
Die interne Kommunikation und der wesentliche Signalfluss innerhalb des Diagnose-Managers sind in 12 dargestellt. Als zentrales Element mit Bezug zu allen Abläufen im Diagnose-Manager ist das Modul „Coordination Manager” von entscheidender Bedeutung für die Systemabläufe. Die Planung der Systemabläufe hängt von den Ergebnissen der Diagnosen („Diagnostic Manager”) sowie den Anforderungen aus den Blöcken „Statistic-Tools”, „System Manager” und „Production/End of Line/Garage” ab. Als Kommunikationsschnittstellen zu den anderen Blöcken der Architek tur dienen der SysCoordBus und der xxxStatusBus, wobei „xxx” Platzhalter für Synonyme der Blocknamen, also stellvertretend für beispielsweise „Diagnosefunktion” steht. Die Generierung eines eindeutigen Diagnoseergebnisses (Pinpointing) ist Aufgabe des Moduls „Symptom Manager”, der die Auswertung (einschließlich Vorentprellung), der Informationen von dem Block a.), also der Sensorschnittstelle (SensorStatusBus), und Block b.), also der Aktuator-Schnittstelle (ActuatorStatusBus, also für „xxx” steht hier „Actuator”), und dem Block g.), also der Diagnosefunktion (DiagnosisBus), übernimmt. Sein Ergebnis kommuniziert er an das Modul „Diagnostic Manager” und über den DiagResultBus. Das Modul „Diagnostic Manager” realisiert die Fehlerspeichereinträge, deren Verwaltung und Übermittlung an den Block c.), also der Kommunikations-Schnittstelle über die (ComInBus/ComOutBus). Das Modul „Statistic-Tools” greift auf Ergebnisse des „Diagnostic Manager” sowie weitere Systeminformationen aus verschiedenen Bussen zu. Im Rahmen z. B. der IUMPR greift er auch auf den „Coordination Manager” zu, wobei „IUMPR” für „In use monitor performance ratio” steht und sich auf die Laufhäufigkeit ausgewählter nichtkontinuierlicher Diagnosen bezieht, wobei eine genaue Definition den „Title 13, California Code Regulations, Section 1968.2” zu entnehmen ist, als die für Zertifizierungen in Kalifornien maßgebliche Richtlinie. Die externe Kommunikation erfolgt über die Busse ComInBus und ComOutBus. In den Modulen „System Manager” und „Production/End of Line/Garage” können Funktionalitäten über das Modul „Coordination Manager” aufgerufen und ausgeführt werden (z. B. Kurztrips, Stellgliedtests). Die Kommunikation über die Kommunikationsschnittstelle, also Block c.), über die Busse ComInBus/ComOutBus ermöglicht den Austausch von Daten mit der Peripherie. Benötigte Systeminformationen werden aus dem Systembus entnommen. Zur Unterstützung der Wartung können im Modul „Production/End of Line/Garage” Informationen aus dem DiagnosisBus, dem „Symptom Manager” und dem ”Diagnostic Manager” verwendet werden. Systemintern werden die Anforderungen an den „Coordination Manager” zur Koordinierung weitergeleitet.
Das Modul „Diagnostic Manager” beinhaltet die Erfassung und Verwaltung der Diagnoseergebnisse. Dazu zählen auch die Realisierungen von Funktionalitäten, wie Entprellung und Heilung im Rahmen der On-Board-Diagnose. Zusätzlich werden hier Mechanismen zum Umgang mit FreezeFrames und die Ansteuerung von beispiels weise MIL (Malfunktion Indicator Lamp, Anzeige von Fehlern im Rahmen der OBD), EPCL (Electronic Power Control Lamp, EGAS-Überwachung) bereitgestellt.
Der „Coordination Manager” beinhaltet die Verriegelung und Priorisierung von Funktionen auf Basis von Diagnoseergebnissen und Systemanforderungen. Ausgaben des Moduls sind Funktionsaufrufe. Dies geschieht im Wesentlichen durch eine Priorisierung der Anforderungen und damit der Funktionsabläufe, eine entsprechende Freigabe oder Sperrung von Funktionen in Abhängigkeit von Systemzustand und Diagnoseergebnissen (über SysCoordBus) und die Überwachung der Funktionsabläufe (über xxxStatusBus).
Dem „Symptom Manager” obliegt die Verarbeitung der Diagnoseergebnisse aus den Blöcken a.), b.) und g.), also der Sensor-Schnittstelle, der Aktuator-Schnittstelle und der Diagnosefunktion. Zur Sicherstellung des Pinpointings ist eine entsprechende Querverriegelungsmatrix zu generieren. Zur Vermeidung von Fehlalarmen (irrtümliche Anzeige eines Fehlers) sind Vorentprellungen (z. B. zeitlich oder ereignisorientiert) innerhalb des Modules „Symptom Manager” vorzusehen.
Das Modul „Statistik-Tools” umfasst u. a. Funktionen zur Berechnung der IUMPR im Rahmen der OBD. Optional können hier auch weitere statistische Auswertefunktionen und kundenspezifische Systemanalysefunktionen hinterlegt werden.
Im Rahmen des Moduls „Produktion/End of Line/Garage” werden Funktionalitäten aus den Bereichen Produktion, Bandende und Werkstatt vorgehalten. Als Beispiele seien hier die Einleitung von Kurztrips und Stellgliedtests sowie die Realisierung von Anpassungskanälen und die Durchführung der Steuergerätecodierung genannt.
Im Modul „System Manager” werden Funktionen, wie z. B. WIV (Wartungsintervallverlängerung) und WFS (Wegfahrsperre) hinterlegt.
Weiterhin wird der Block h.), also der Controller, im Detail dargestellt. Der Block h.), also der Controller, generiert aus den vom Block d.), also dem Beobachter/der Signalverarbeitung, vom Block f.), also dem Rekonfigurator, vom Block e.), also dem Diagnose-Manager, vom Block c.), also der Kommunikations-Schnittstelle und vom Block g.), also der Diagnosefunktion, zur Verfügung gestellten Signalen Ansteuerungen der Aktuatoren, d. h. der Controller enthält sämtliche Funktionen zur Steuerung und Regelung von Motor und Antriebsstrang. Die zu einer bestimmten Hardwarekomponente gehörende Steuerungs-/Regelungsfunktion lässt sich somit als entsprechendes Modul identifizieren. Der Block h.) umfasst die Module „PtCtl” (Powertrain Control; Antriebsstrangkoordination), „ExCtl” (Exhaust System Control; Steuerung/Regelung Abgassystem), „EffCoord” (Efficiency Coordination; Wirkungsgradkoordination), „TqCtl” (Torque Control; Momenten-Steuerung/Regelung), „AirCtl” (Air System Control; Steuerung/Regelung Luftsystem), „CmbCtl” (Combustion Control; Steuerung/Regelung Verbrennung), „FuCtl” (Fuel System Control; Steuerung/Regelung Kraftstoffsystem), „ThCtl” (Thermal System Control; Steuerung/Regelung Kühlsystem) und „ActCtl” (Actuator Control; Steuerung/Regelung Aktuatoren). Der prinzipielle Signalfluss innerhalb des Blockes h.) ist in 13 dargestellt. Von links nach rechts lassen sich vier Kaskaden ausmachen, beginnend von der eher prozessfernen Fahrerwunschinterpretation im Modul „PtCtl” über die Momentensteuerung/-regelung im Modul „TqCtl”, die Prozessregler des Moduls „AirSysCtl” bis hin zum Drosselklappenlageregelkreis im Modul „ActCtl”. Insgesamt lässt sich das Zusammenspiel der Module wie folgt beschreiben. Im Modul „PtCtl”, dem Antriebsstrangmanagement, wird aus der Fahrpedalstellung und weiteren Größen ein Sollmoment berechnet. Das Modul „ExSysCtl” erzeugt Wirkungsgradanforderungen zum Aufheizen und Abkühlen von Komponenten des Abgasstranges. Der Momentenwunsch dient als Sollwert für die Funktionen des Moduls „TqCtl”, das von zentraler Bedeutung ist. Es dient zur Kapselung des Verbrennungsmotors als Momentenstellglied und enthält hierzu ein inverses Momentenmodell, das den Momentensollwert und die koordinierten Wirkungsgradanforderungen aus „ExSysCtl” in entsprechende Sollwerte für Prozessgrößen, wie Füllung und Raildruck, sowie in weitere motorische Sollwerte abbildet. Das Modul „AirSysCtl” wandelt Füllungs- und/oder Drucksollwerte in eine entsprechende Waste-Gate-Ansteuerung und einen Drosselklappensollwinkel um. Das Modul „CmbCtl” enthält u. a. die Zündwinkelberechnung und die Gemischsteuerung und -regelung. Das Modul „FuSysCtl” steuert und regelt vor allem die Kraftstoffdrücke. Das Modul „ThSysCtl” steuert und regelt die Kühlmitteltemperatur. Das Modul „ActCtl” enthält Funktionen zur Regelung unterlagerter Aktuatoren, wie z. B. die Drosselklappe. Sämtliche Stellgrößen inklusive etwaiger binärer Größen zur Freigabe/Deaktivierung von Endstufen werden in einem Signalbus, dem ControlBus, zusammengefasst. Eine Ausnahme bilden hierbei Stellsignale, die über den CAN verschickt werden sollen, z. B. an eine E-Maschine. Diese werden in einem gesonderten Signalbus, dem ComControlBus, zusammengefasst.
Entsprechend der Darstellung des prinzipiellen Signalflusses innerhalb des Blockes h.) gemäß 13 verläuft der Hauptsignalpfad in horizontaler Richtung von links nach rechts. Jedes Modul innerhalb des Blockes h.) beziehungsweise jede Funktion kann auf die Informationen von Block d.), f.), g.) und Block e.) in der erfindungsgemäßen Struktur zugreifen. Das im Modul „PtCtl” innerhalb des Blockes h.) enthaltene Antriebsmanagement erhält zusätzlich über die Kommunikations-Schnittstelle, also von Block c.), externe Sollwertanforderungen (z. B. Sollmoment von ASR). Da eine Verbrennungskraftmaschine einen verkoppelten Prozess darstellt, sind auch die einzelnen Reglerfunktionen nicht vollständig unabhängig voneinander. Wie der von Modul „CmbCtl” zum Modul „FuSysCtl” gezeichnete gestrichelte Pfeil kennzeichnet, ist auch ein vertikaler Signalfluss möglich und erforderlich. In diesem speziellen Fall handelt es sich um eine Aufschaltung des von der Gemischsteuerung generierten Kraftstoffsollvolumenstromes auf die Raildruckreglerfunktion im Sinne einer Entkopplung/Störgrößenaufschaltung. Das Modul „PtCtl” stellt das Antriebsmanagement dar und umfasst die Funktionen Fahrerwunschinterpretation, Fahrerassistenzsysteme (Fahrgeschwindigkeitsregler, Drehzahl- und Geschwindigkeitsbegrenzer), Momentenbegrenzung, Beschleunigungsschnittstelle, Fahrbarkeitsfilter Beschleunigungssteuerung und -regelung, Momentenschnittstelle, Aggregatekoordination (Hybridkoordinator und Fahrstrategie), Ruckeldämpfer, Leerlauf- und Anfahrregler, Drehzahlschnittstelle. Wesentliche Ausgangsgrößen sind das Sollmoment für das Modul „TqCtl” sowie Stellsignale (z. B. Sollmoment oder Sollgang) für externe Aggregate, die über einen Bus, wie z. B. den CAN, verschickt werden. Basierend auf einem inversen Momentenmodell des Verbrennungsmotors wandelt das Modul „TqCtl” das Sollmoment und die Sollwirkungsgrade aus „ExCtl” in entsprechende Sollwerte, u. a. für Füllung, Kraftstoffhochdruck, Luftzahlwirkungsgrad, Zündwinkelwirkungsgrad, Wirkungsgrade von interner und externer Abgasrückführung, Tumblewirkungsgrad. Ferner ist die Entscheidung über den Brennverfahrensmodus (Homogen, Schicht, GCI) Bestandteil dieses Moduls. Das Modul „ExSysCtl” umfasst Funktionen zur Steuerung und Regelung des Abgassystems. Hierzu zählen beispielsweise Funktionen zum Katheizen, Bauteileschutz (Katalysatoren und Turbine) und zur Rauchbe grenzung. Ausgangsgrößen sind Sollwirkungsgrade/Sollmomente für Zündung und Lambda sowie die Anforderung zur Leerlaufdrehzahlanhebung. Das Modul „AirSysCtl” umfasst Funktionen zur Steuerung und Regelung von Lade- und Saugrohrdruck bzw. Füllung. Das Modul „FuSysCtl” umfasst Funktionen zur Steuerung und Regelung von Kraftstoffniederdruck und Kraftstoffhochdruck, zur Tankentlüftung sowie zur Entlüftung des Kraftstoffsystems. Das Modul „CmbCtl” enthält Funktionen zur Zünd- und Einspritzventilansteuerung, zur Lambda-Regelung und Lambdasondenheizungsregelung sowie zur Klopfregelung. Das Modul „ActCtl” enthält Funktionen zur Steuerung und Regelung von Aktuatoren, z. B. den Drosselklappenlageregelkreis. Das Modul „ThSysCtl” enthält Funktionen zum Thermomanagement. Hierzu zählt vor allem die Lüfteransteuerung.
Weiterhin wird der Block g.), also die Diagnosefunktion, im Detail dargestellt. Steigende gesetzliche und technische Anforderungen an moderne Motormanagementsysteme machen die ständige Prüfung und Überwachung des Gesamtsystems einschließlich seiner Sensoren, Aktuatoren, Komponenten und Teilsysteme notwendig. Das minimale Ziel besteht dabei in der Erfüllung der gesetzlichen Auflagen im Rahmen der OBD. Darüber hinaus soll die geführte Störungs- und Fehlersuche in Service und Werkstatt unterstützt sowie die Umsetzung kundenspezifischer Wünsche ermöglicht werden. Ziel ist es, Störungen und Fehler frühzeitig zu erkennen, zu lokalisieren und zu identifizieren, um Folgeschäden an Motor und Fahrzeug vermeiden zu können. Der Block g.) beinhaltet alle Systemdiagnosen, die nicht in den Bereich der Low-Level-Diagnosen im Block a.), b) oder c.) fallen oder zum E-Gas-Monitoring im Block l.) gehören.
Die Strukturierung des Blockes g.) erfolgt in Anlehnung an die Struktur in den Blöcken d.) und h.), also dem Beobachter und dem Controller. Der Aufbau von Block g.) ist in 14 dargestellt.
Zur Abbildung der gesetzlichen Anforderungen wird im Block g.) eine weitere Modul-Ebene eingeführt. Hintergrund ist die in der Gesetzgebung verankerte höhere Auflösung der Komponenten in Hinblick auf abgasrelevante Bauteile. Die zusätzliche Modulebene wird in 15 für die Umsetzung der in Kalifornien maßgeblichen Richtlinie „Title 13, California Code Regulations, Section 1968.2" vorgestellt.
Die Kommunikation innerhalb des Blockes g.) verläuft in vertikaler Richtung von oben nach unten. Als Eingangsgrößen werden die Residuen (ResidueBus), Modell- und Sensorgrößen (ModelBus bzw. SensorBus) sowie Freigaben (über SysCoordBus) verarbeitet. Ausgaben des Blockes sind, neben den Diagnoseergebnissen selbst (DiagnosisBus), der Status einzelner Diagnosen (DiagnosisStatusBus) und, falls eine aktive Diagnose erforderlich ist, Anforderungen an den Controller (DiagnosisControlBus). Die Struktur ist in 16 gezeigt.
Auf der zweiten (Sub-)Modulebene erfolgt die Gliederung in Anlehnung an die Gesetzgebung. Mit Bezug auf den in 15 dargestellten Fall werden die zu realisierenden Submodule im Folgenden aufgelistet. Eine Liste der konkreten Funktionen ist nicht Bestandteil dieser Offenbarung, da diese in Abhängigkeit von Antriebskonzept und Sensor-Aktuator-Konfiguration variiert. Ziel der zweiten Modulebene ist es, eine Zuordnung zwischen den realisierten Diagnosefunktionen und den gesetzlichen Bestimmungen zu bekommen. Das Submodul „Air System Monitoring” umfasst Funktionen zur Realisierung von „Evaporative System Monitoring”, „Variable Valve Timing and/or Control System Monitoring”, „Positive Crankcase Ventilation System Monitoring” und „Comprehensive Component Monitoring” auf Basis der Richtlinie Title 13, California Code Regulations, Section 1968.2. Das Submodul „Fuel System Monitoring” umfasst Funktionen zur Realisierung von „Fuel System Monitoring” und „Comprehensive Component Monitoring” auf Basis der Richtlinie Title 13, California Code Regulations, Section 1968.2. Das Submodul „Combustion System Monitoring” umfasst Funktionen zur Realisierung von „Misfire Monitoring” und „Comprehensive Component Monitoring” auf Basis der Richtlinie Title 13, California Code Regulations, Section 1968.2. Das Submodul „Exhaust System Monitoring” umfasst Funktionen zur Realisierung von „Catalyst Monitoring”, „Heated Catalyst Monitoring”, „Secondary Air System Monitoring”, ”Direct Ozone Reduction System Monitoring”, „Other Emission Control or Source System Monitoring”, ”Exhaust Gas Sensor Monitoring”, ”Cold Start Emission Reduction Strategy Monitoring”, ”Exhaust Gas Recirculation System Monitoring” und ”Comprehensive Component Monitoring” auf Basis der Richtlinie Title 13, California Code Regulations, Section 1968.2. Das Submodul „Powertrain System Monitoring” umfasst Funktionen zur Realisierung von „Air Conditioning System Component Monitoring” und „Comprehensive Component Monitoring” auf Basis der Richtlinie Title 13, California Code Regulations, Section 1968.2. Das Submodul „Thermal System Monitoring” umfasst Funktionen zur Realisierung von „Engine Cooling System Monitoring” und „Comprehensive Component Monitoring” auf Basis der Richtlinie Title 13, California Code Regulations, Section 1968.2.
Weiterhin wird der Block f.), also der Rekonfigurator, im Detail dargestellt. Die Rekonfiguration (Umgestaltung, Neuordnung) des Systems ist als Werkzeug zur Realisierung von fehlertoleranten Systemen zu verstehen. Die Rekonfiguration greift dabei auf Ressourcen im System zurück, um den Betrieb auch im Fehlerfall sicherzustellen. Der weitere Betrieb kann dabei möglicherweise nur zum Teil, mit reduzierter Performanz und/oder für eine begrenzte Zeit erfolgen. Grundlage eines fehlertoleranten Systems und damit für die Durchführung einer Rekonfiguration ist eine leistungsfähige Diagnose, die ein präzises Pinpointing ermöglicht. Aufgabe des Blockes f.) ist es, den Systembetrieb und die Systemperformanz trotz eines auftretenden Fehlers im System aufrecht zu erhalten, mindestens jedoch einen „Limp Home” Mode zu realisieren (Vermeidung von Liegenbleibern). Der Block f.) dient zur Anpassung und Umschaltung des Systems im Fehlerfall. Im Rahmen dieses Blockes sollen Funktionen und Rückfallebenen hinterlegt werden, die im Sinne eines fehlertoleranten Systems einen sicheren Betrieb des Motors über den Zeitpunkt eines Fehlerauftrittes hinaus gewährleisten. Die grundsätzliche Struktur des Blockes f.) ist in 17 skizziert. Analog zu Block d.) und Block h.) erfolgt die Gliederung der Komponenten/Module. Damit können die zu einer bestimmten Systemkomponente gehörenden Rekonfigurationsstrategien einem Modul zugeordnet werden.
Der Block f.) umfasst die den einzelnen Modulen zugeordneten Rekonfigurationsstrategien, die sich in Ausprägung und Umfang unterscheiden. Dabei ist anzumerken, dass der Block f.) nur dann aktiv ist, wenn ein Fehler im System aufgetreten ist, diagnostiziert wurde und vom Diagnose-Manager in Block e.) eine entsprechende Rekonfigurationsanforderung an den Block f.) gestellt wurde.
Abhängig von der jeweiligen Rekonfigurationsstrategie kann der Block f.) auf den Block d.), h.) oder auf den Block d.) und auf den Block h.) gemeinsam zugreifen. Das Prinzip ist in 18 schematisch für das Modul „Air System” dargestellt. Als Beispiel für eine einfache Umsetzung wird auf 10 und den dazugehörigen Text verwiesen. Je nach Systemkonfiguration und Fehlersituation kann hier auf verschie dene Ersatzwerte für einen Sensorwert umgeschaltet werden. Die Rekonfigurationsstrategien sind hochgradig von dem System und der verwendeten Sensor-Aktuator-Konfiguration abhängig. Hinzu kommt, dass jede Rekonfigurationsmaßnahme im Fehlerfall als Einzelfall geprüft werden muss (Sicherheit, Systemstabilität). Aus diesen Gründen werden die Strategien als einzelne Funktionen (Software-Komponenten) in den jeweiligen Modulen abgelegt. Die Kommunikation innerhalb des jeweiligen Moduls verläuft in horizontaler Richtung von links nach rechts. Als Eingangsgrößen werden die Diagnoseergebnisse (DiagResultBus) und die Freigaben (über SysCoordBus) verarbeitet. Ausgaben des Blockes sind die Stati der einzelnen Rekonfigurationsfunktionen (ReconfigStatusBus) und die jeweiligen Rekonfigurationsmaßnahmen (ReconfigBus). Mit anderen Worten generiert jede Strategie (Funktion) aus den Eingangsgrößen entsprechend der hinterlegten Funktionalität Ausgangsgrößen, die in das System beziehungsweise die erfindungsgemäße modulare Struktur umfassend die Blöcke a.) bis h.) verteilt. Entscheidend ist dabei, dass jede Rekonfigurations-Strategie für sich isoliert zu betrachten ist und keine Querkopplungen beziehungsweise -verbindungen zwischen den Strategien bestehen.
ZITATE ENTHALTEN IN DER BESCHREIBUNG
Diese Liste der vom Anmelder aufgeführten Dokumente wurde automatisiert erzeugt und ist ausschließlich zur besseren Information des Lesers aufgenommen. Die Liste ist nicht Bestandteil der deutschen Patent- bzw. Gebrauchsmusteranmeldung. Das DPMA übernimmt keinerlei Haftung für etwaige Fehler oder Auslassungen.
Zitierte Patentliteratur

- DE 10044319 A1 [0002]

Zitierte Nicht-Patentliteratur

- Title 13, California Code Regulations, Section 1968.2 [0079]
- Richtlinie „Title 13, California Code Regulations, Section 1968.2” [0090]
- Richtlinie Title 13, California Code Regulations, Section 1968.2 [0092]
- Richtlinie Title 13, California Code Regulations, Section 1968.2 [0092]
- Richtlinie Title 13, California Code Regulations, Section 1968.2 [0092]
- Richtlinie Title 13, California Code Regulations, Section 1968.2 [0092]
- Richtlinie Title 13, California Code Regulations, Section 1968.2 [0092]
- Richtlinie Title 13, California Code Regulations, Section 1968.2 [0092]

Claims

Vorrichtung zur Steuerung und Regelung eines Antriebssystems, die einen Computerprogrammcode umfasst, wobei der Computerprogrammcode in mehrere Blöcke strukturiert ist, wobei die Blöcke Funktionen zur Steuerung und Regelung eines Antriebssystems als abgrenzbare Bestandteile des Computerprogrammcodes umfassen, wobei mindestens ein Block eine Aktuator-Schnittstelle umfasst, welcher Funktionen zur Verarbeitung von Stellsignalen und deren Weiterleitung an Aktuatoren/Endstufen zugeordnet sind, wobei die Aktuator-Schnittstelle zwei Ebenen umfasst, wobei die erste Ebene Funktionen zur Umwandlung von Stellsignalen in Eingangssignale von Funktionen zur Ansteuerung der Aktuatoren/Endstufen umfasst, wobei die erste und die zweite Ebene durch eine Laufzeitumgebung voneinander getrennt sind, wobei die zweite Ebene die Funktionen zur Ansteuerung der Aktuatoren/Endstufen umfasst.
Vorrichtung nach Patentanspruch 1, wobei die erste Ebene für jeden einzelnen mit der Aktuator-Schnittstelle verbundenen Aktuator eine diesem Aktuator zugeordnete Komponente umfasst, welche die Funktionen zur Umwandlung der diesen Aktuator betreffenden Stellsignale in Eingangssignale der Funktionen zur Ansteuerung der Aktuatoren/Endstufen umfasst, wobei die zweite Ebene für jeden einzelnen mit der Aktuator-Schnittstelle verbundenen Aktuator eine diesem Aktuator zugeordnete Komponente umfasst, welche die Funktionen zur Ansteuerung der Aktuatoren/Endstufen umfasst.
Vorrichtung nach Patentanspruch 1 oder 2, wobei die Aktuator-Schnittstelle mit einem Controller zusammenwirkt, wobei der Controller Stellsignale bereitstellt, wobei der Controller in einzelne Module gegliedert ist, wobei die Module physikalisch beschreibbare Komponenten des Antriebssystems darstellen, wobei die der ersten Ebene für jeden einzelnen mit der Aktuator-Schnittstelle verbundenen Aktuator zugeordneten Komponenten ebenfalls in Module gegliedert sind, wobei die Gliederung der Module der Gliederung des Controllers entspricht.
Vorrichtung nach Patentanspruch 1 bis 3, wobei die zweite Ebene der Aktuator-Schnittstelle Funktionen zur Diagnose der Aktuatoren/Endstufen umfasst, wobei für jeden einzelnen mit der Aktuator-Schnittstelle verbundenen Aktuator eine Funktion zur Diagnose vorgesehen ist.
Vorrichtung nach Patentanspruch 1 bis 4, wobei die Aktuator-Schnittstelle mit einem Diagnose-Manager zusammenwirkt, wobei in Abhängigkeit des Ergebnisses der der zweiten Ebene der Aktuator-Schnittstelle zugeordneten Funktionen zur Diagnose der Aktuatoren/Endstufen mittels des Diagnose-Managers eine Verwaltung der Fehlerinformationen erfolgt.
Vorrichtung nach Patentanspruch 1 bis 5, wobei die Aktuator-Schnittstelle Bestandteil einer zur Steuerung und Regelung eines Antriebssystems aus mehreren Blöcken gebildeten modularen Struktur eines Computerprogrammcodes ist, wobei jeweils mindestens ein Block für a.) eine Sensor-Schnittstelle, b.) eine Aktuator-Schnittstelle, c.) eine Kommunikations-Schnittstelle, d.) einen Beobachter/eine Signalverarbeitung, e.) einen Diagnose-Manager, f.) einen Rekonfigurator, g.) eine Diagnosefunktion, h.) einen Controller, vorgesehen ist, wobei die Blöcke a.) bis h.) zum Austausch von Daten/Informationen miteinander verbunden sind, wobei den Blöcken a.) bis h.) Funktionen zugeordnet werden, wobei in Abhängigkeit des Antriebskonzeptes des zu Grunde liegenden Antriebssystems und/oder der Anzahl/Eigenschaften der verwendeten Sensoren oder Aktoren die den Blöcken a.) bis h.) zugeordneten Funktionen festgelegt werden.