Warning: fopen(111data/log202007061140.log): failed to open stream: No space left on device in /home/pde321/public_html/header.php on line 107

Warning: flock() expects parameter 1 to be resource, boolean given in /home/pde321/public_html/header.php on line 108

Warning: fclose() expects parameter 1 to be resource, boolean given in /home/pde321/public_html/header.php on line 113
Steuergerät und Computerprogramm zum Steuern eines Antriebsaggregates eines Fahrzeugs - Dokument DE102004008869A1
 
PatentDe  


Dokumentenidentifikation DE102004008869A1 02.09.2004
Titel Steuergerät und Computerprogramm zum Steuern eines Antriebsaggregates eines Fahrzeugs
Anmelder Robert Bosch GmbH, 70469 Stuttgart, DE
Erfinder Thomas, Martin, 76703 Kraichtal, DE;
Hoenninger, Harald, 79114 Freiburg, DE;
Illg, Bernd, 75031 Eppingen, DE;
Tischer, Christian, 71282 Hemmingen, DE;
Kind, Werner, 71706 Markgröningen, DE
Vertreter Dreiss, Fuhlendorf, Steimle & Becker, 70188 Stuttgart
DE-Anmeldedatum 20.02.2004
DE-Aktenzeichen 102004008869
Offenlegungstag 02.09.2004
Veröffentlichungstag im Patentblatt 02.09.2004
IPC-Hauptklasse B60K 41/00
IPC-Nebenklasse B60R 16/02   
Zusammenfassung Die Erfindung betrifft ein Steuergerät und ein Computerprogramm zum Steuern einer Vorrichtung (300) eines Fahrzeugs mit Hilfe einer zwischen das Steuergerät (100) und die Vorrichtung (300) geschalteten Sensor-/Aktor-Konfiguration (200). Das Steuergerät (100) umfasst eine Hardware (110a) und eine Software (100b). Um einzelne Teile der Software (100b) einfach austauschbar und unabhängig voneinander realisierbar zu gestalten, wird erfindungsgemäß vorgeschlagen, diese Software in geeigneter Weise zu modularisieren. Insbesondere um eine vereinfachte Hinzufügung von Anwendersoftware zu ermöglichen, die keine domänenspezifischen Kenntnisse voraussetzt, wird erfindungsgemäß vorgeschlagen, dass die Software (100b) ein erstes Modul (ASV) aufweist, in dem diejenigen Funktionseinheiten zusammengefasst sind, welche eine Realisierung von Steuerungs-, Sicherheits- und/oder Überwachungsfunktionen für die Vorrichtung (300) ermöglichen.

Beschreibung[de]

Die Erfindung betrifft ein Steuergerät und ein Computerprogramm zum Steuern einer Vorrichtung, insbesondere einer Brennkraftmaschine eines Fahrzeugs.

Stand der Technik

Derartige Steuergeräte mit jeweils einer Hardware und einer Software sind im Stand der Technik grundsätzlich bekannt. Die Hardware dieser Steuergeräte umfasst typischerweise mindestens einen Prozessor und mindestens ein Speicherelement. Die Software dieser Steuergeräte umfasst dagegen typischerweise eine Vielzahl von in dem Speicherelement hinterlegten Funktionseinheiten mit jeweils unterschiedlichen Funktionen. Zum Zwecke der Ansteuerung einer Vorrichtung des Fahrzeug kommunizieren zumindest einzelne dieser Funktionseinheiten miteinander. Die unmittelbare Ansteuerung der Vorrichtung erfolgt auf Basis der abgespeicherten Software mit Hilfe einer zwischen das Steuergerät und die Vorrichtung geschalteten Sensor-/Aktor-Konfiguration.

Die erwähnten Funktionseinheiten wurden jedoch nicht alle gleichzeitig entwickelt und in der Software implementiert, sondern sind erst im Laufe der Zeit im Zuge fortschreitender Entwicklung sukzessive zu der Software des Steuergerätes hinzugefügt worden. Bei der Hinzufügung neuer Funktionseinheiten hat man bisher lediglich darauf geachtet, dass die neuen Funktionseinheiten mit allen anderen Funktionseinheiten, soweit erforderlich, kommunizieren konnten. Im Laufe der Zeit entstand so ein unübersichtliches Agglomerat von Schnittstellen zwischen den einzelnen Funktionseinheiten, was insbesondere einen Austausch bekannter Funktionseinheiten durch modifizierte Funktionseinheiten oder die weitere Hinzufügung von neuen Funktionseinheiten zunehmend schwieriger machte. Die Schwierigkeiten entstanden insbesondere deshalb, weil bestehende Abhängigkeiten zwischen einzelnen Funktionseinheiten bei einer Umgestaltung des Gesamtsystems, bestehend aus Steuergerät inklusive Hardware und Software, Sensor-/Aktor-Konfiguration und Vorrichtung oder auch nur von Teilen desselben nur noch sehr schwer überschaubar waren.

Ausgehend von diesem Stand der Technik ist es die Aufgabe der vorliegenden Erfindung, ein bekanntes Steuergerät und ein Computerprogramm zum Steuern einer Vorrichtung eines Fahrzeugs derart weiterzubilden, dass einzelne Teile des Steuergerätes und insbesondere von dessen Computerprogramm unabhängig voneinander realisierbar und austauschbar sind.

Diese Aufgabe wird durch den Gegenstand des Patentanspruchs 1 gelöst. Demnach ist die Software des Steuergerätes modular in Form einer Mehrzahl von Modulen aufgebaut, die zum Zwecke einer modulübergreifenden Kommunikation durch eine Mehrzahl von Modulschnittstellen miteinander verbunden sind und wobei in einem ersten der Module diejenigen der Funktionseinheiten zusammengefasst sind, welche eine Realisierung von Steuerungs-, Sicherheits- und/oder Überwachungsfunktionen für die Vorrichtung ermöglichen.

Die Vorrichtung im Sinne der Erfindung kann alternativ verschiedene Domänen eines Fahrzeugs repräsentieren. So kann sie das Antriebsaggregat des Fahrzeugs als eine erste Domäne repräsentieren; die Vorrichtung ist dann beispielsweise in Form einer Brennkraftmaschine, eines Elektroantriebs oder eines Brennstoffzellenantriebs ausgebildet. Alternativ dazu kann die Vorrichtung auch als Getriebe ausgebildet sein und auf diese Weise eine zweite Domäne des Fahrzeugs repräsentieren.

Benutzer im Sinne der Erfindung kann zum Beispiel der Fahrer des Fahrzeugs, der Gesetzgeber, ein Fahrzeugzulieferer oder ein Fahrzeughersteller sein.

Physikalische Ebene im Sinne der Erfindung bedeutet eine Abstraktion von Hardware-Spezifika. Dies bedeutet, dass in der physikalischen Ebene, bezogen auf die Schnittstelle des Sensors zu seiner Umgebung, lediglich physikalische Größen wie zum Beispiel die Drehzahl des Antriebsaggregates betrachtet werden, nicht jedoch deren hardwaremäßige Realisierung in Form eines elektronischen Signals mit einer hardware-spezifischen, die Drehzahl repräsentierenden Amplitude oder Frequenz.

Die Begriffe Software und Computerprogramm werden in der Beschreibung grundsätzlich synonym verwendet.

Vorteile der Erfindung

Der wesentliche Vorteil der beanspruchten Modularisierung besteht darin, dass die einzelnen Module einfach austauschbar und unabhängig voneinander realisierbar sind. Ein Austausch einzelner Module ist insbesondere deshalb besonders einfach, weil in den definierten Modul-Schnittstellen zwischen den einzelnen Modulen alle Abhängigkeiten zwischen den Funktionseinheiten in den verschiedenen Modulen berücksichtigt sind; darüber hinausgehende Abhängigkeiten können zwar noch auf Ebene der Funktionseinheiten existieren, sind aber auf Ebene der übergeordneten Module gekapselt und daher nicht mehr sichtbar; sie brauchen deshalb bei einem Austausch der Module nicht mehr berücksichtigt zu werden.

Mit der vorgeschlagenen Modularisierung sind insbesondere Kosten- und Zeitersparnisse verbunden. Bei Verwendung einer anderen Steuergerätehardware oder einer anderen Sensor-/Aktor-Konfiguration braucht nun nicht mehr die gesamte Software des Steuergerätes analysiert und gegebenenfalls angepasst zu werden, sondern es ist vielmehr ausreichend, wenn nur das entsprechende Modul betrachtet wird.

Die beanspruchte Zusammenfassung der genannten Funktionseinheiten zu dem ersten Modul wurde so gewählt, dass sie insbesondere aus Sicht der Fahrzeughersteller und aus physikalischer Sicht sinnvoll ist.

Das beanspruchte erste Modul wird vorzugsweise vom Hersteller des Steuergerätes als eine Art Basissoftwaremodul mitgeliefert. Vorteilhafterweise erlaubt es aufgrund seiner definierten Schnittstellen zu den anderen Modulen eine einfache Integration dieser anderen Module in die Gesamtsoftware des Steuergerätes auch dann, wenn diese anderen Module oder Teile davon nicht von dem Hersteller des Steuergeräts, sondern von Dritten, zum Beispiel den Automobilherstellern selbst, entwickelt beziehungsweise programmiert wurden. Das gilt insbesondere für ein fünftes, sogenanntes Anwender-Software-Modul. Hohe Aufwendungen zur Anpassung inkompatibler Schnittstellen, welche die Realisierung von Plattformlösungen bei den Automobilherstellern oder deren Zulieferer stark behindern, gehören damit der Vergangenheit an.

Die in dem ersten Modul zusammengefassten Funktionseinheiten sind alle jeweils für eine konkrete Vorrichtung des Fahrzeugs ausgebildet. Damit ist auch das erste Modul als Ganzes quasi zwangsläufig vorrichtungs- beziehungsweise domänenspezifisch ausgebildet. Durch die Zusammenfassung der domänenspezifischen Funktionseinheiten in dem ersten Modul können domänenspezifische Infrastruktur-Funktionseinheiten aus anderen Modulen, insbesondere aus dem CORE-Modul herausgehalten werden, so dass dieses zumindest weitgehend domänenunabhängig und damit einfacher und wiederverwendbar für andere Domänen programmiert werden kann.

Die in dem ersten Modul zusammengefassten Funktionseinheiten repräsentieren Funktionen mit hoher Bedeutung für das zuverlässige Funktionieren des Gesamtsystems bestehend aus Steuergerät, Sensor-/Aktor-Konfiguration und Vorrichtung. Diese Funktionseinheiten sind deshalb diesbezüglich oftmals sehr spezifisch und umfassen zum Teil geschützte, das heißt geheime Schnittstellen, zum Beispiel um eine Manipulation des Systems von außen zu verhindern. Die Zusammenfassung derartiger Funktionseinheiten in dem ersten Modul ermöglicht eine klare Zuweisung der Verantwortung für diese Teile zu dem Hersteller des ersten Moduls, üblicherweise dem Steuergeräte-Anbieter. Die durch die beanspruchte Ausbildung des ersten Moduls bedingte Trennung beziehungsweise Separierung dieser kritischen Funktionseinheiten von anderen Modulen, insbesondere dem Anwender-Software-Modul, ermöglicht vorteilhafterweise eine einfachere Entwicklung beziehungsweise Programmierung dieser anderen Module (ASW); dies gilt deswegen, weil dann dafür kein spezifisches Know-how über die in dem ersten Modul zusammengefassten kritischen Funktionseinheiten erforderlich ist. Insbesondere ist damit eine Programmierung von Fahrzeug- und Motorfunktionen auch unter Verwendung von zentralen Steuersignalen des Steuergerätes für das Anwender-Software-Modul möglich, ohne dass dafür Kenntnisse über die sensiblen Funktionseinheiten in dem ersten Modul erforderlich wären.

Neben dem ersten Modul und dem Anwender-Software-Modul weist die Software des Steuergerätes typischerweise ein zweites Modul, auch "Core" genannt, auf, in dem diejenige Funktionseinheiten zusammengefasst sind, welche eine individuelle Programmierung des Prozessors des Steuergerätes in der Weise ermöglichen, dass die Hardware des Steuergerätes in die Lage versetzt wird, mit den Modulen des Steuergerätes zu kommunizieren und welche die Abarbeitung von Funktionen der Funktionseinheiten in den Modulen ermöglicht. Der CORE stellt eine Abstraktion von der Hardware zur Verfügung, so dass die Anwendersoftware unabhängig von der Steuergeräte-Hardware entwickelt und verwendet werden kann.

Als drittes Modul kann ein sogenannter Komplex-Treiber vorgesehen sein, in dem diejenigen Funktionseinheiten zusammengefasst sind, die eine direkte Ansteuerung von speziellen Sensor-Aktor-Konfigurationen ermöglichen, und eine von der Steuergeräte-Hardware abhängige Implementierung erfordern.

Die Agglomeration von erstem, zweiten und dritten Modul wird nachfolgend auch als U-Layer bezeichnet. Optional kann darüber hinaus auch ein viertes Modul, eine sogenannte Gerätekapselung, vorgesehen sein, in dem diejenigen Funktionseinheiten zusammengefasst sind, die eine individuelle Anpassung an die verwendeten Sensor-/Aktor-Konfiguration in der Software des Steuergeräts in der Weise ermöglichen, dass zwischen den einzelnen Sensoren oder Aktoren der Konfiguration eine Kommunikation mit den übrigen Modulen des Steuergerätes möglich ist.

Vorzugsweise sind alle Module der Erfindung zwecks wechselseitiger Kommunikation über Modulschnittstellen M1–M6 und M1', M2' und M3' miteinander verbunden.

Zumindest ein Teil der Module, insbesondere das zweite Modul, sind ihrerseits wiederum in Komponenten unterteilt. Einzelne der Komponenten sind erforderlichenfalls einfach austauschbar, ohne dass dann jeweils ein komplettes Modul ausgetauscht werden müsste.

Notwendigerweise sind auch zwischen den Komponenten und Modulen Schnittstellen für einen Datenaustausch vorgesehen. Vorteilhafterweise erfolgt eine Kommunikation zwischen Komponenten in unterschiedlichen Modulen über genau definierte, stabile Modul-Schnittstellen.

Jede der Komponenten ist ihrerseits wiederum in beliebig viele Funktionseinheiten unterteilt. Schnittstellen sind auch auf Ebene dieser Funktionseinheiten vorgesehen, so dass verschiedene Funktionseinheiten innerhalb einer Komponente miteinander kommunizieren können. Eine Kommunikation zwischen Funktionseinheiten in unterschiedlichen Komponenten erfolgt über die Komponentenschnittstellen und eine Kommunikation zwischen Funktionseinheiten in unterschiedlichen Modulen erfolgt über die Modul-Schnittstellen.

Auch für die Schnittstellen zwischen den Funktionseinheiten und zwischen den Komponenten gilt das bereits oben für die Abhängigkeiten im Allgemeinen Gesagte, nämlich dass innerhalb von Modulen alle notwendigen internen Abhängigkeiten zwischen den Funktionseinheiten untereinander berücksichtigt sind und keine interne Abhängigkeiten auf Modulebene sichtbar werden. Daraus resultiert eine einfache Austauschbarkeit nicht nur von Modulen, sondern auch von Komponenten oder Funktionseinheiten, das heißt insbesondere eine einfache und unkomplizierte Anpassung an Kundenwünsche oder neue Technologien.

Eine nähere Beschreibung der Aufteilung sowie der Aufgaben der einzelnen Komponenten in den Modulen und der in den einzelnen Komponenten zusammengefassten Funktionseinheiten ist Gegenstand der Unteransprüche.

Gemäß einer vorteilhaften Ausbildung sind die Funktionseinheiten, die Komponenten und/oder die Module sowie deren jeweilige Schnittstellen zumindest teilweise als Computerprogramm ausgebildet. Die Ausbildung als Computerprogramm erlaubt eine flexible Umsetzung von Änderungswünschen, ohne dass eine Änderung der Hardware des Steuergerätes vorgenommen werden muss.

Die oben genannte Aufgabe wird weiterhin durch ein Computerprogramm für das beschriebene und beanspruchte Steuergerät gelöst. Die Vorteile dieses Computerprogramms entsprechen den oben mit Bezug auf das Steuergerät erwähnten Vorteilen.

Zeichnungen

Der Beschreibung sind insgesamt sechs Figuren beigefügt, wobei

1 den Aufbau eines der Erfindung zugrunde liegenden Gesamtsystems;

2 eine erfindungsgemäße Modularchitektur für ein Steuergerät;

3 eine erfindungsgemäße Unterteilung einzelner Module in Komponenten;

4 die erfindungsgemäße Zuordnung von Funktionseinheiten zu einer Infrastruktur-Komponente und einer Hardwarekapsel-Komponente; und

5 eine Funktionseinheit für ein Gerätetreiber-Element zeigt.

Beschreibung der Ausführungsbeispiele

Es folgt eine detaillierte Beschreibung von Ausführungsbeispielen der Erfindung unter Bezugnahme auf die Figuren.

1 zeigt ein Gesamtsystem mit einem Steuergerät 100, wobei das Bezugszeichen 100a die Hardware und das Bezugszeichen 100b die Software des Steuergerätes 100 repräsentiert. Die Hardware des Steuergerätes 100 umfasst wenigstens einen Prozessor 100a-1 und wenigstens ein Speicherelement 100a-2. Die Software 100b ist üblicherweise in dem Speicherelement 100a-2 hinterlegt. Die Software 100b umfasst üblicherweise eine Vielzahl von Funktionseinheiten EPM, IS-1, IS-2, HWE-1, STE, ÜF, SF die zumindest vereinzelt zum Zwecke der Ansteuerung einer Vorrichtung 300 dieses Fahrzeugs miteinander kommunizieren. Die unmittelbare Ansteuerung der Vorrichtung 300 erfolgt in dem Gesamtsystem mit Hilfe einer zwischen das Steuergerät 100 und das Antriebsaggregat 300 geschalteten Sensor-/Aktor-Konfiguration 200.

Beispiele für Funktionseinheiten in der Software 100b für das Steuergerät 100 zum Ansteuern der Vorrichtung 300, insbesondere als Antriebsaggregat, sind:

  • – Funktionseinheit Aggregat-Positions-Management EPM: Diese Funktionseinheit hat die Aufgabe, eine Positions- und Drehzahlerfassung der Kurbel- und Nockenwelle des Antriebsaggregates durchzuführen.
  • – Funktionseinheit Dienstebibliotheken IS-1: Sie hat die Aufgabe, allgemeine, sehr häufig verwendete Funktionen bereitzustellen, die von unterschiedlichen Funktionseinheiten nachgefragt beziehungsweise benutzt werden. Sie bietet eine zentrale Bereitstellung dieser Funktionen mit dem Vorteil, dass diese nicht mehrfach dezentral bereitgestellt werden müssen.
  • – Funktionseinheit Diagnosemanager IS-2: Diese Funktionseinheit übernimmt die Aufbereitung eines Fehlersignals, welches zum Beispiel einen Defekt in der Hardware 100a des Steuergerätes 100 repräsentiert. Die Aufbereitung besteht insbesondere in einer Entprellung des Fehlersignals und einer Abspeicherung desselben, damit zu einem späteren Zeitpunkt eine Auswertung des Fehlersignals erfolgen kann.
  • – Funktionseinheit Signalaufbereitung HWE-1: Sie führt eine Bereinigung eines analogen Sensorsignals nach dessen Digitalisierung durch zum Beispiel im Hinblick auf unerwünschte Signalmodulationen, die in dem Steuergerät eventuell entstanden sein können.
  • – Funktionseinheit Steuerungsfunktion STE: Sie dient zur Generierung beziehungsweise zur Gewährleistung einer zeit- beziehungsweise drehzahlabhängigen Ansteuerung der Vorrichtung und koordiniert die zeitliche Abarbeitung von Anforderungen unterschiedlicher Funktionseinheiten. Insbesondere wenn es sich bei der Vorrichtung um das Antriebsaggregat des Fahrzeugs handelt, dann ist eine Ansteuerung von zum Beispiel den Einspritzventilen und eine Einstellung des Zündzeitpunktes zwingend notwendig mit der Drehzahl oder dem Kurbelwellenwinkel zu synchronisieren zwecks Festlegung geeigneter Umschaltzeitpunkte zwischen Betriebszuständen der Vorrichtung. Ganz generell lässt sich der Betrieb der Vorrichtung in eine Initialisierungsphase, eine Normalbetriebsphase und eine Abschaltphase unterteilen; diese unterschiedlichen Betriebsphasen sind in der Software des Steuergerätes abgebildet. Die Initialisierungsphase dient typischerweise zwecks Definition beziehungsweise Vorbesetzung von Variablen zur Systemsteuerung. Wenn es sich bei der Vorrichtung um eine Brennkraftmaschine mit Direkteinspritzung handelt, kann während des Normalbetriebs zunächst zum Beispiel ein Homogenbetrieb eingestellt und als Betriebszustand überwacht werden. Bei Erreichen vorbestimmter Änderungs- oder Umschaltkriterien kann die Funktionseinheit STE dann innerhalb des Normalbetriebs eine Umschaltung von Homogen- auf Schichtbetrieb mit Lambda ≥ 1 veranlassen.
  • – Funktionseinheit Überwachungsfunktionen ÜF: Sie dient zur Überwachung des Betriebs der Vorrichtung. Die ÜF-Funktionseinheit gewährleistet, dass die Vorrichtung keine unzulässigen Betriebszustände einnimmt. So darf beispielsweise ein Antriebsaggregat als Vorrichtung während des Betriebs des Fahrzeugs niemals mehr Drehmoment liefern als vom Fahrer gewünscht.
  • – Funktionseinheit Schutzfunktionen SF: Die Funktionseinheit Schutzfunktionen ist ausgebildet, eine unautorisierte Nutzung der Vorrichtung 300 beziehungsweise des Fahrzeugs zu verhindern. So kann sie insbesondere ausgebildet sein, eine unzulässige Manipulation von Daten, insbesondere in der Software des Steuergerätes oder eine unzulässige Inbetriebnahme beziehungsweise einen Diebstahl der Vorrichtung oder des Fahrzeugs zu verhindern.

Einzelne dieser Funktionseinheiten sind in 1 innerhalb der Software 100b des Steuergerätes beispielhaft veranschaulicht.

2 zeigt eine erfindungsgemäße Modularisierung der Software 100b in dem Steuergerät 100. Die durch die Modularisierung gebildeten Softwaremodule ASV, CO, DE, CD, ASW zeichnen sich dadurch aus, dass in ihnen Funktionseinheiten jeweils geeignet zusammengefasst beziehungsweise gruppiert werden.

Erfindungsgemäß werden in einem ersten Modul ASV diejenige Funktionseinheiten STE, ÜF und SF zusammengefasst, welche eine Realisierung von Steuerungs-, Sicherheits- und/oder Überwachungsfunktionen für die Vorrichtung 300 ermöglichen. Die Zusammenfassung der beschriebenen Funktionseinheiten repräsentiert eine domänenspezifische Steuerungs- und Kontrollinstanz, das heißt eine Steuerung, welche gezielt auf die anzusteuernde Vorrichtung 300 angepasst ist. Anders ausgedrückt sind diese Funktionseinheiten beziehungsweise ist diese Zustandssteuerung dann individuell daraufhin abgestimmt, ob es sich bei der anzusteuernden Vorrichtung um ein Antriebsaggregat oder eine Getriebesteuerung etc. handelt. Bezüglich Detailaufgaben der einzelnen Funktionseinheiten sei auf die Ausführungen zu den einzelnen Funktionseinheiten in der obigen Liste der Funktionseinheiten verwiesen. Basierend auf den grundlegenden Mechanismen des nachfolgend beschriebenen zweiten Moduls CO entsteht durch das erfindungsgemäße erste Modul ASV ein domänenspezifischer Rahmen, welcher die Einbindung eines weiter unten noch näher beschriebenen fünften Moduls Anwendersoftware ASW für einen jeweiligen Einsatz bestmöglich unterstützt.

In einem zweiten Modul CO werden zum einen diejenigen Funktionseinheiten IS-1, IS-2 und HWE-1 zusammengefasst, welche eine individuelle Programmierung der Hardware des Steuergerätes 100 in der Weise ermöglichen, dass die Hardware in die Lage versetzt wird, mit den Modulen des Steuergerätes 100 zu kommunizieren. Weiterhin umfasst das zweite Modul CO diejenigen Funktionseinheiten, welche eine Abarbeitung von Funktionen der Funktionseinheiten in den Modulen ASV, ASW, CO, DE, CD erst ermöglichen (Betriebssystem, Speicherverwaltung). Darüber hinaus kann das zweite Modul CO auch solche Funktionseinheiten aufweisen, welche eine Kommunikation des Moduls ASW und/oder eines vierten Moduls DE mit anderen Steuergeräten ermöglichen.

In einem dritten Modul Complex Driver CD werden diejenigen Funktionseinheiten zusammengefasst, die eine direkte Ansteuerung von komplexen Sensor-/Aktor-Konfigurationen mit komplexen Schnittstellen zu dem Steuergerät 100 durch das erste Modul ermöglichen. Diese spezifischen Sensor-/Aktor-Konfigurationen sind von den nicht-spezifischen und nicht von der Steuergerät-Hardware abhängigen Sensor-/Aktor-Konfigurationen zu unterscheiden. Im Unterschied zu nicht-spezifischen Konfigurationen, bei denen eine Kommunikation mit einem später noch näher beschriebenen fünften Modul ASW nur über das zweite und ein viertes Modul möglich ist, erfolgt bei den spezifischen Konfigurationen eine Kommunikation mit dem fünften Modul ASW direkt über das dritte Modul DE.

In dem vierten Modul DE werden diejenigen Funktionseinheiten zusammengefasst, die eine individuelle Anpassung der verwendeten Sensor-/Aktor-Konfiguration an das Steuergerät 100 in der Weise ermöglichen, dass zwischen den einzelnen Sensoren oder Aktoren der Konfiguration eine Kommunikation mit den übrigen Modulen des Steuergerätes 100 möglich ist.

Schließlich werden in dem fünften Modul Anwender-Software ASW werden diejenigen Funktionseinheiten zusammengefasst, die zur Beeinflussung der Vorrichtung 300 im Ansprechen auf einen Benutzerwunsch auf physikalischer Ebene dienen.

Zwischen den Modulen ASV, ASW, CO, DE, CD sind jeweils Modul-Schnittstellen M1, M2, M3, M4, M5, M6 und M7 vorgesehen, die zum einen eine Kommunikation der Module untereinander, aber auch den Austausch einzelner Module ermöglichen. So dient die Schnittstelle M1 zwischen dem ersten Modul ASV und dem zweiten Modul CO dazu, dass das erste Modul ASV die grundlegenden Mechanismen des zweiten Moduls benutzen kann, um bspw. auf die Hardware des Steuergerätes zuzugreifen oder um aufgetretene Fehler abzuspeichern. Über die Schnittstellen M2, M3 und M7 überwacht das erste Modul ASV das dritte, vierte und fünfte Modul bezüglich der korrekten Abarbeitung der ihnen gestellten Aufgaben und bringt das Fahrzeug bei einer fehlerhaften Abarbeitung der Aufgaben in einen sicheren Zustand. Außerdem informiert das erste Modul das dritte, vierte und fünfte Modul über den Betriebszustand des Steuergerätes mit der Konsequenz, dass diese informierten Module dann die ihnen bei dem jeweiligen Betriebszustand des Steuergerätes zugeordneten Aufgaben abarbeiten. Neben der Schnittstelle M7 weist das fünfte Modul ASW typischerweise noch weitere direkte Modulschnittstellen zu den Modulen CO, DE und CD auf.

Grundsätzlich können die erwähnten Module unabhängig voneinander je nach Anwendungsfall im erforderlichen Umfang vorgesehen sein. Eine besonders vorteilhafte Kombination repräsentieren das erste, zweite und dritte Modul, nachfolgend auch als U-Layer U bezeichnet. Ein solcher U-Layer umfasst alle notwendigen Treiber für Standard-Ein- und Ausgangsgrößen und die komplexen Signale einer jeweils verwendeten Sensor-/Aktor-Konfiguration 200. Darüber hinaus sind die komplexen Kopplungen zwischen einer nachfolgend beschriebenen Komponente HWE des zweiten Moduls CO und dem dritten Modul CD implementiert und es bestehen keinerlei Zugriffskonflikte mehr zwischen der Komponente HWE und dem vierten Modul DE beim Zugriff auf gemeinsame Hardware-Ressourcen. Bei einem solchen U-Layer U benutzt das erste Modul ASV die Methoden und Dienste des zweiten Moduls CO und die Eingangssignale des dritten Moduls CD, um vorrichtungsspezifische Steuersignale zu ermitteln, aber auch um die für seine Steuerungsfunktion erforderlichen Zeitraster konfigurieren und bereitstellen zu können. Die Funktion einer Wegfahrsperre innerhalb der Funktionseinheit Schutzfunktion des ersten Moduls ASV weist Schnittstellen zu der Komponente HWE innerhalb des zweiten Moduls CO sowie zu sogenannten Abschaltpfaden beziehungsweise Komplextreibern innerhalb des dritten Moduls CD auf; diese Schnittstellen sind vorteilhafterweise in dem U-Layer gekapselt und brauchen bei einer Programmierung weiterer Module deshalb nicht mehr berücksichtigt zu werden. Neben diesen Schnittstellen sind auch Schnittstellen der Funktionseinheit Überwachung der Hardware und Schnittstellen der Funktionseinheit Schutzfunktion bereits innerhalb des U-Layers gelöst und gekapselt. Im Rahmen seiner Funktionseinheit Überwachungsfunktion kann das erste Modul ASV auch Mechanismen zur Abschaltung der Vorrichtung im Fehlerfalle bereitstellen.

Das Steuergerät 100 stellt zusammen mit dem U-Layer eine ideale Plattform beziehungsweise ein ideales Framework zur Entwicklung von Anwendersoftware durch Dritte oder zur Nutzung vorhandener Anwendersoftware dar. Der Hauptgrund dafür ist darin zu sehen, dass aufgrund der U-Layer-Struktur die Entwicklung der Anwendersoftware weitestgehend ohne Berücksichtigung von grundlegenden komplexen und Hardware-abhängigen domänenspezifischen Aufgabenstellungen erfolgen kann, welche kein Differenzierungspotential bieten oder hohe Relevanz für die Robustheit des Gesamtsystems und die Gewährleistung der Funktionen des Gesamtsystems haben. Bei den grundlegenden domänenspezifischen Funktionen handelt es sich insbesondere um die notwendigen Grundfunktionen Einspritzung, Zündung, Positionserfassung, Systemsteuerung, Überwachung oder Wegfahrsperre, wie sie oben bereits im Rahmen des Funktionsumfangs des ersten Moduls beziehungsweise des Complex Drivers CD beschrieben wurden. Die erwähnte Vereinfachung bei der Programmierung von Anwendersoftware auf Basis des beanspruchten U-Layers U hat den Vorteil, dass man sich bei der Programmierung der Anwendersoftware voll auf für die Anwendersoftware wichtige Teilaspekte konzentrieren kann. Bei diesen Teilaspekten kann es sich zum Beispiel um Bedürfnisse des späteren Fahrers eines Fahrzeugs mit dem Gesamtsystem oder um Anforderungen des Gesetzgebers handeln. Bei den Bedürfnissen des Fahrers kann es sich beispielsweise um die Aspekte "Fahrspaß" oder "Kraftstoffverbrauch" handeln, während es sich bei den Forderungen des Gesetzgebers beispielsweise um die Einhaltung von Emissionsgrenzwerten oder die Möglichkeit der Realisierung von Diagnosefunktionen handeln kann. Schließlich ermöglicht der U-Layer U ein einfaches Umstellen beziehungsweise Wechseln der Hardware des Steuergerätes, ohne dass in diesen Fällen die Anwender-Software (ASW) gewechselt werden und damit auf deren bewährte Funktionalitäten verzichtet werden müsste.

Wird der U-Layer U durch das oben beschriebene vierte Modul DE ergänzt, so bietet das den Vorteil, dass der Nutzer weiterhin von einer komplexen Diagnose und Überwachung von Ein- und Ausgangsgrößen der Sensor-/Aktor-Konfiguration 200, die ebenfalls gewährleistungs- und sicherheitsrelevant sind, entlastet wird.

3 zeigt eine erfindungsgemäße Gruppierung von Komponenten innerhalb der zuvor beschriebenen Module ASW, und CO. Das fünfte Modul ASW repräsentiert im Wesentlichen anwender- bzw. benutzerorientierte Funktionen. Im Hinblick auf geplante Anwendungsfälle, bei denen Vorrichtungen unterschiedlicher Domänen, wie Antriebsaggregate oder Getriebe, durch das Steuergerät angesteuert werden sollen, ist es sinnvoll, dieses Modul ASW in eine Fahrzeug-Komponente VF und eine Antriebsaggregate-Komponente EF zu unterteilen.

Die Fahrzeug-Komponente VF umfasst vorzugsweise diejenigen Funktionseinheiten, die nicht spezifisch für einen bestimmten Typ von Antriebsaggregat sind, wie beispielsweise Diesel-, Benzin- oder Elektromotor. Dabei handelt es sich – wenn die Vorrichtung als Antriebsaggregat ausgebildet ist – insbesondere um die Funktionseinheiten Antrieb VF-1, Fahrzeugkoordinator VF-2, Fahrzeugbewegung VF-3 oder Fahrzustandsgrößen VF-4, wie sie oben beschrieben wurden.

Demgegenüber sind dann in der Antriebsaggregate-Komponente EF vorzugsweise alle diejenigen Funktionseinheiten zusammengefasst, die für das verwendete Antriebsaggregat als Vorrichtung 300 spezifisch sind, wie beispielsweise Klopfregelung, Einspritzung, Zündung, Abgasnachbehandlung, Leerlaufregelung. Bei einem Wechsel der von dem Steuergerät 100 anzusteuernden Vorrichtung 300 ist es dann nicht mehr erforderlich, das komplette erste ASW-Modul auszutauschen, sondern es genügt vorteilhafterweise, wenn lediglich die Antriebsaggregate-Komponente EF ausgetauscht wird.

Ähnlich wie bei dem Modul ASW empfiehlt es sich bei dem zweiten Modul CO zum Beispiel im Hinblick auf verschiedene in dem Steuergerät 100 verwendbare Prozessoren, das zweite Modul CO in eine Infrastruktur-Komponente IS und in eine Hardwarekapsel-Komponente HWE zu unterteilen. In der Infrastruktur-Komponente IS sind vorzugsweise alle diejenigen Funktionseinheiten zusammengefasst, welche grundlegende Dienste anbieten oder repräsentieren, auf die andere Funktionseinheiten zugreifen können. Dabei handelt es sich vorzugsweise um die Funktionseinheiten Dienstebibliotheken IS-1 und Diagnosemanager IS-2, wie ebenfalls oben beschrieben. Die Dienste dieser Funktionseinheiten werden in der Infrastruktur-Komponente an zentraler Stelle bereitgestellt und müssen deshalb nicht dezentral in mehrfacher Ausfertigung vorliegen und unnötig Speicherplatz beanspruchen.

In der Hardwarekapsel-Komponente HWE sind alle diejenigen Funktionseinheiten zusammengefasst, welche eine individuelle Programmierung der Hardware 100a des Steuergerätes 100 in der Weise ermöglichen, dass die Hardware 100a in die Lage versetzt wird, mit den Modulen ASV, ASW, CO, DE oder CD des Steuergeräts 100 zu kommunizieren. So ist es bei einem Austausch des in dem Steuergerät 100 verwendeten Prozessors durch einen Prozessor anderen Typs lediglich erforderlich, die Hardwarekapsel-Komponente HWE und nicht mehr das gesamte zweite Modul des Steuergerätes auszutauschen.

Neben der genannten Infrastruktur-Komponente und der Hardwarekapsel-Komponente kann das zweite Modul CO optional weiterhin eine Kommunikations-Komponente COM aufweisen, in welcher diejenigen Funktionseinheiten zusammengefasst sind, welche eine Kommunikation mit anderen Steuergeräten (hier nicht gezeigt) ermöglichen.

Neben den bereits oben erwähnten Modul-Schnittstellen M1 ... M7 auf Modulebene sind auch Komponentenschnittstellen auf Ebene der Komponenten innerhalb der einzelnen Module vorgesehen. Diese Komponentenschnittstellen K0 ... K3 ermöglichen einen Datenaustausch zwischen zumindest einzelnen der Komponenten innerhalb eines Moduls. So besteht eine Schnittstelle K0 in dem Modul ASW zwischen der Fahrzeug-Komponente VF und der Antriebsaggregate-Komponente EF. Innerhalb des zweiten Moduls CO besteht eine Komponentenschnittstelle K1 zwischen der Infrastruktur-Komponente IS und der Kommunikations-Komponente COM, eine zweite Schnittstelle K2 zwischen der Infrastruktur-Komponente IS und der Hardwarekapsel-Komponente HWE und eine dritte Schnittstelle K3 zwischen der Hardwarekapsel-Komponente HWE und der Kommunikations-Komponente COM.

4 zeigt die bereits beschriebene Zuordnung von oben erläuterten Funktionseinheiten IS-1 und IS-2, zu der Infrastruktur-Komponente IS und der Funktionseinheit HWE-1 zu der Hardwarekapsel-Komponente HWE innerhalb des zweiten Moduls CO. Die Funktionseinheiten innerhalb einer Komponente können über Funktionseinheiten-Schnittstellen F7 untereinander kommunizieren. Eine Kommunikation zwischen Funktionseinheiten, die unterschiedlichen Komponenten innerhalb desselben Moduls zugeordnet sind, erfolgt über die besagte Komponentenschnittstelle, beispielsweise K2.

5 veranschaulicht die bereits erwähnte vorteilhafte Unterteilung des dritten Moduls CD in mindestens eine Funktionseinheit. Bei dieser Funktionseinheit handelt es sich beispielsweise um die einleitend beschriebene Funktionseinheit Aggregate-Positions-Management EPM, die einen Komplexgerätetreiber repräsentiert. Komplexgerätetreiber innerhalb des dritten Moduls werden vorteilhafterweise vom Hersteller des Steuergeräts programmiert, da eine starke Kopplung zur Steuergerät-Hardware vorhanden ist.

Die Funktionseinheiten, Komponenten oder Module werden vorzugsweise als Computerprogramme realisiert. Dann ist es möglich, diese Computerprogramme, gegebenenfalls zusammen mit weiteren Computerprogrammen zur Steuerung der Vorrichtung, auf einem computerlesbaren Datenträger abzuspeichern. Bei dem Datenträger kann es sich um eine Diskette, eine Compact Disc, einen sogenannten Flash-Memory oder dergleichen handeln. Das auf dem Datenträger abgespeicherte Computerprogramm kann dann als Produkt an einen Kunden verkauft werden. Außerdem ist es im Fall einer Softwarerealisierung möglich, das Computerprogramm, wiederum gegebenenfalls zusammen mit weiteren Computerprogrammen, auch ohne die Zuhilfenahme eines Datenträgers, über ein elektronisches Kommunikationsnetzwerk als Produkt an einen Kunden zu übertragen und auf diese Weise zu verkaufen. Bei dem Kommunikationsnetzwerk kann es sich zum Beispiel um das Internet handeln.


Anspruch[de]
  1. Steuergerät (100) zum Steuern einer Vorrichtung (300) eines Fahrzeugs, insbesondere einer Brennkraftmaschine oder eines Getriebes, mit Hilfe einer zwischen das Steuergerät (100) und die Vorrichtung (300) geschalteten Sensor-/Aktor-Konfiguration (200);

    wobei das Steuergerät eine Hardware (100a) mit wenigstens einem Prozessor (100a-1) und wenigstens einem Speicherelement (100a-2) und eine Software (100b) mit einer Vielzahl von in dem Speicherelement (100a-2) hinterlegten Funktionseinheiten umfasst;

    dadurch gekennzeichnet, dass die Software (100b) modular in Form einer Mehrzahl von Modulen aufgebaut ist, die zum Zwecke einer modulübergreifenden Kommunikation durch eine Mehrzahl von Modulschnittstellen (M1–M7) miteinander verbunden sind; und in einem ersten (ASV) der Module diejenigen Funktionseinheiten zusammengefasst sind, welche eine Realisierung von Steuerungs-, Sicherheits- und/oder Überwachungsfunktionen für die Vorrichtung ermöglichen.
  2. Steuergerät nach Anspruch 1, dadurch gekennzeichnet, dass das erste Modul (ASV) eine Modulschnittstelle (M7) zum Anschluss eines Anwender-Software-Moduls (ASW) aufweist.
  3. Steuergerät (100) nach Anspruch 2, dadurch gekennzeichnet, dass das Anwender-Software-Modul (ASW) aufweist:

    – eine Fahrzeug-Komponente (VF), in welcher diejenigen Funktionseinheiten zusammengefasst sind, die nicht spezifisch für einen bestimmten verwendeten Typ von Antriebsaggregat (300) sind; und

    – eine Antriebsaggregate-Komponente (EF), in welcher diejenigen Funktionseinheiten zusammengefasst sind, die für den verwendeten Typ von Antriebsaggregat (300) spezifisch sind.
  4. Steuergerät (100) nach einem der vorangegangenen Ansprüche, dadurch gekennzeichnet, dass die Software (100b) ein zweites Modul (CO) aufweist, in dem diejenigen Funktionseinheiten zusammengefasst sind, welche eine individuelle Programmierung des Prozessors (100a-1) des Steuergerätes in der Weise ermöglichen, dass die Hardware (100a) in die Lage versetzt wird, mit den Modulen des Steuergeräts (100) zu kommunizieren und welche die Abarbeitung von Funktionen der Funktionseinheiten in den Modulen ermöglicht, wobei die ASW-Komponenten (VF, EF) unabhängig von der konkreten Ausführung des Steuergeräts (HW) sind.
  5. Steuergerät (100) nach Anspruch 4, dadurch gekennzeichnet, dass das zweite Modul (CO) aufweist:

    – eine Infrastruktur-Komponente (IS), in welcher diejenigen Funktionseinheiten zusammengefasst sind, welche grundlegende Dienste anbieten oder repräsentieren, auf die andere Funktionseinheiten zugreifen können; und

    – eine Hardwarekapsel-Komponente (HWE), in welcher diejenigen Funktionseinheiten zusammengefasst sind, welche eine individuelle Programmierung der Hardware (100a) des Steuergerätes (100) in der Weise ermöglichen, dass die Hardware in die Lage versetzt wird, mit den Modulen (ASW, CO, DE, CD) des Steuergeräts (100) zu kommunizieren.
  6. Steuergerät (100) nach Anspruch 5, dadurch gekennzeichnet, dass die Infrastruktur-Komponente (IS) vorzugsweise die Funktionseinheiten Dienstebibliotheken (IS-1) und/oder Diagnosemanager (IS-2) umfasst.
  7. Steuergerät (100) nach einem der Ansprüche 5 oder 6, dadurch gekennzeichnet, dass die Hardwarekapsel-Komponente (HWE) insbesondere eine Funktionseinheit Signalaufbereitung (HWE-1) umfasst.
  8. Steuergerät (100) nach einem der Ansprüche 4–7, dadurch gekennzeichnet, dass das zweite Modul (CO) weiterhin eine Kommunikations-Komponente (COM) aufweist, in welcher diejenigen Funktionseinheiten zusammengefasst sind, welche eine Kommunikation mit anderen Steuergeräten ermöglichen.
  9. Steuergerät nach einem der vorangegangenen Ansprüche, dadurch gekennzeichnet, dass die Software ein drittes Modul (CD) aufweist, in dem diejenigen Funktionseinheiten zusammengefasst sind, die eine direkte Ansteuerung von spezifischen Sensor-Aktor-Konfigurationen ermöglichen.
  10. Steuergerät (100) nach Anspruch 9, dadurch gekennzeichnet, dass das dritte Modul (CD) insbesondere eine Funktionseinheit Aggregate-Positions-Management (EPM) aufweist.
  11. Steuergerät (100) nach einem der vorangegangenen Ansprüche, dadurch gekennzeichnet, dass die Software (100b) ein viertes Modul (DE) aufweist, in dem diejenigen Funktionseinheiten zusammengefasst sind, die eine individuelle Anpassung der verwendeten Sensor-/Aktor-Konfiguration (300) an das Steuergerät (100) in der Weise ermöglichen, dass zwischen den einzelnen Sensoren oder Aktoren der Konfiguration eine Kommunikation mit den übrigen Modulen des Steuergerätes möglich ist.
  12. Steuergerät (100) nach einem der vorangegangenen Ansprüche, dadurch gekennzeichnet, dass zumindest in dem zweiten Modul (CO) und/oder in dem Anwender-Software-Modul (ASW) Komponentenschnittstellen (K0 ... K3) für einen Datenaustausch zwischen zumindest einzelnen der Komponenten (IS, COM, HWE) innerhalb des Moduls, insbesondere aber auch zwischen Funktionseinheiten in unterschiedlichen Komponenten, vorgesehen sind.
  13. Steuergerät nach einem der Ansprüche 5 bis 12, dadurch gekennzeichnet, dass innerhalb einer Komponente (VF, EF, IS, HWE, COM) Funktionseinheiten-Schnittstellen (Fi) für einen Datenaustausch zwischen zumindest einzelnen der Funktionseinheiten innerhalb derselben Komponente vorgesehen sind.
  14. Steuergerät (100) nach einem der vorangegangenen Ansprüche, dadurch gekennzeichnet, dass die Funktionseinheiten, die Komponenten und/oder die Module sowie die Schnittstellen zwischen ihnen zumindest teilweise als Computerprogramm ausgebildet sind.
  15. Computerprogramm für ein Steuergerät (100) gemäß einem der Ansprüche 1–14 zum Steuern einer Vorrichtung (300) eines Fahrzeugs, umfassend einen Programmcode, der geeignet ist, die Funktionseinheiten, Komponenten oder Module abzubilden und eine Kommunikation zwischen diesen zum Zwecke der Steuerung der Vorrichtung zu realisieren.
Es folgen 4 Blatt Zeichnungen






IPC
A Täglicher Lebensbedarf
B Arbeitsverfahren; Transportieren
C Chemie; Hüttenwesen
D Textilien; Papier
E Bauwesen; Erdbohren; Bergbau
F Maschinenbau; Beleuchtung; Heizung; Waffen; Sprengen
G Physik
H Elektrotechnik

Anmelder
Datum

Patentrecherche

Patent Zeichnungen (PDF)

Copyright © 2008 Patent-De Alle Rechte vorbehalten. eMail: info@patent-de.com