-
Die
Erfindung betrifft ein Steuergerät
und ein Netzwerk für
eine Mehrzahl von Vorrichtungen, insbesondere in einem Kraftfahrzeug
(Kfz). Darüber
hinaus betrifft die Erfindung ein Verfahren zum Ausrüsten eines
Fahrzeugs mit mindestens einem derartigen Steuergerät oder Netzwerk.
-
Steuergeräte, Netzwerke
und Verfahren der genannten Art sind im Stand der Technik grundsätzlich bekannt.
Ein Steuergerät umfasst
dabei üblicherweise
ein Softwarepaket und eine Steuereinrichtung, auf welcher das Softwarepaket
abläuft.
Im Bereich der Fahrzeugelektronik wird als Steuereinrichtung vielfach
ein Mikrocontroller verwendet zum Interagieren mit diversen Vorrichtungen
des Fahrzeugs. Bei diesen Vorrichtungen kann es sich insbesondere
um den Motor, das Getriebe, ein Anti-Blockier-System, einen Sitz
oder ein Schließsystem
des Fahrzeuges handeln. Die Vorrichtungen werden üblicherweise von
dem Mikrocontroller über
ein Peripherieelement im Ansprechen auf Befehle des Softwarepaketes
angesteuert.
-
Für das Softwarepaket
ist es insbesondere im Bereich der Fahrzeugtechnik, zum Beispiel
aus dem VDI-Bericht Nr. 1646, 2001, Seite 249 bis Seite 276, "Softwareentwicklung
für Steuergeräte im Systemverbund – Von der
Cartronic-Domänenstruktur zum
Gerätecode", bekannt, dieses
domänenspezifisch
auszubilden. Dabei meint der Begriff "domänenspezifische
Ausbildung" in dem
genannten Stand der Technik eine Strukturierung der Software nach
funktionalen und nicht-funktionalen Anforderungen. Funktionale Anforderungen
sind dabei zum Beispiel die Gewährung
einer Rundumsicht, welche durch ein Wischersystem umgesetzt wird.
Nichtfunktionale Anforderungen sind dagegen beispielsweise qualitative oder
geschäftliche
Anforderungen an einzelne Vorrichtungen des Fahrzeugs.
-
Diesem
soeben beschriebenen Aufbau bekannter Steuergeräte haftet der Nachteil an,
dass er für
eine Standardisierung der Steuergeräte nur bedingt geeignet ist.
Mit dem in dem VDI-Bericht
beschriebenen Konzept der domänenspezifischen
Ausbildung des Softwarepaketes für
ein Steuergerät
wird zwar ein gewisser Grad an Standardisierung für insbesondere
die Software der Steuergeräte
erreicht; es hat sich jedoch gezeigt, dass dieser Ansatz beim Versuch
einer weiteren Standardisierung sehr schnell an seine Grenzen stößt.
-
Ausgehend
von diesem Stand der Technik ist es deshalb die Aufgabe der Erfindung,
ein Steuergerät
und ein Netzwerk für
eine Mehrzahl von Vorrichtungen sowie ein Verfahren zum Ausrüsten eines Fahrzeugs
mit mindestens einem dieser Steuergeräte oder Netzwerke derart weiterzubilden,
dass eine weitergehende Standardisierung der Steuergeräte möglich wird,
so dass diese für
eine wesentlich größere Vielzahl
von Anwendungen eingesetzt werden können.
-
Diese
Aufgabe wird durch den Gegenstand des Patentanspruchs 1 gelöst. Demnach
haben die von dem Steuergerät
anzusteuernden Vorrichtungen zumindest ähnliche Anforderungen an das
Steuergerät,
repräsentiert
die Klasse dieser zumindest ähnlichen
Anforderungen die Domäne
und ist die Steuereinrichtung des Steuergerätes für die Domäne spezifisch als Domain-Controller
ausgebildet.
-
Vorrichtungen
im Sinne der Erfindung können
grundsätzlich
beliebige Vorrichtungen sein, die über Aktoren elektrisch/elektronisch
ansteuerbar sind und die gegebenenfalls über Sensoren Rückmeldungen
geben können.
-
Der
Vorteil der beanspruchten Domänenbildung
ist darin zu sehen, dass sie bereits in einem sehr frühen Stadium
eines Entwicklungsprozesses, nämlich
bereits vor der Spezifikation des Steuergerätes, ansetzt und nicht erst – wie aus
dem Stand der Technik bekannt – bei
der Spezifikation von Anwendungen oder Funktionen, die mit einem
vorgegebenen Steuergerät
realisiert werden sollen. Wichtig ist auch, dass sich die erfindungsgemäße Domänenbildung
im Unterschied zum Stand der Technik nicht lediglich auf die Software
des Steuergerätes,
sondern auch auf dessen Hardware, insbesondere dessen Steuereinrichtung,
erstreckt. Die domänenspezifisch ausgebildete
Steuereinrichtung, das heißt
der Domain-Controller,
und der domänenspezifische
Anteil des Softwarepaketes, sind für alle unterschiedlichen Anwendungsfälle innerhalb
einer Domain identisch. Insofern bildet die beanspruchte Definition
einer Domäne
und die darauf basierende domänenspezifische
Ausbildung der Software und der Hardware des Steuergerätes die
Grundlage für
eine sehr weitreichende, weiter unten näher beschriebene Standardisierung/Modularisierung
des Steuergeräts
und für daraus
resultierende Kostenvorteile.
-
Gemäß einer
vorteilhaften Ausgestaltung weist der Domain-Controller eine vorzugsweise domänenneutral
ausgebildete Busschnittstelle auf. Daran angeschlossene Peripherieelemente
müssen zwangsläufig busfähig sein.
Eine derartige Ausbildung des Domain-Controllers und der Peripherieelemente
bietet den Vorteil, dass in dem Domain-Controller keine für die einzelnen
Peripherieelemente spezifische Hardware vorgesehen werden muss.
Der Hardwareaufwand zur Ansteuerung der Peripherieelemente wird
damit aus dem Domain-Controller in die Peripherieelemente verlagert.
Dieses Konzept ist eine weitere Voraussetzung für eine sehr weitreichende Standardisierung
der Steuergeräte
beziehungsweise insbesondere von deren Steuereinrichtungen, den
Domain-Controllern. Sie müssen
nun nicht mehr spezifisch für
eine Vielzahl von unterschiedlichen Peripherieelementen ausgebildet
sein. Die Anzahl der Anwendungsfälle,
für die
ein einzelner Domain-Controllertyp verwendet werden kann, wird dadurch
weiter wesentlich vergrößert. Ein
derartig standardisierter Domain-Controller kann in wesentlich größeren Stückzahlen
hergestellt werden, woraus ganz erhebliche Kostenvorteile resultieren.
Die Kostenvorteile ergeben sich insbesondere bei einer Ausbildung
des Domain-Controllers als integrierte Schaltung. Gleichzeitig ist
die monolithische Integration Voraussetzung für eine einfache, von hoher
Zuverlässigkeit
geprägte,
Realisierung von folienbasierten „intelligenten" Verkabelungstrukturen.
-
Für einen
einzelnen spezifischen Domain-Controller-Typ ist es vorteilhaft,
wenn dieser hinsichtlich seiner Verarbeitungsleistung und/oder seiner
Speichergröße skalierbar
ist. Daraus resultiert ein weiterhin vergrößertes mögliches Einsatzspektrum mit
weiterem Standardisierungspotential und weiteren Kostenvorteilen
für ein
und denselben spezifischen Domain-Controller-Typ.
-
Eine
weitere besonders vorteilhafte Ausgestaltung des Steuergeräts besteht
darin, dass zumindest einzelne (möglichst viele) Einrichtungen
des Domain-Controllers oder einzelne (möglichst viele) Peripherieelemente
als Intellectual Property IP-Einrichtungen ausgebildet sind. Durch
eine derartige Ausbildung werden die Einrichtungen herstellerunabhängig, das
heißt
es kommen viele Lieferanten für
diese Einrichtungen in Frage. Einzelne Teile der Software können als
offene Software-Architekturen
gestaltet werden. Im Unterschied zum Stand der Technik ist dann
keine individuelle softwaremäßige Anpassung von
Softwareanteilen an unterschiedliche Hardwareeinrichtungen, die
deswegen unterschiedlich sind, weil sie von unterschiedlichen Herstellern
stammen, erforderlich.
-
Die
soeben beschriebenen Möglichkeiten zur
Standardisierung der Hardware des Steuergerät, das heißt insbesondere des Domain-Controllers,
ermöglichen
auch eine weitergehende und umfassendere Standardisierung der Software
als dies im Stand der Technik möglich
war.
-
Diese
weitergehende Standardisierung der Software wird zum Beispiel in
Form einer normierten Ablaufsteuerung als domänenspezifischer Teil des Softwarepakets
realisiert. Die Ablaufsteuerung vergleicht im Wesentlichen Eingangsmuster
mit Bedingungsmustern und löst
je nach Ergebnis dieses Vergleiches bestimmte Ereignisse aus. Durch
Bereitstellung dieser Bedingungsmuster, welche auf die in jedem
Einzelfall individuell anzusteuernden Vorrichtungen individuell
angepasst sind, durch eine Parameterdatenbank, ist es möglich, kundenspezifische Funktionen
und Anforderungen in die Software beziehungsweise in die Bedingungsmuster
oder Datensätze
zu verlagern. Der Domain-Controller und die Ablaufsteuerung bleiben
von diesen kundensichtbaren Funktionen unbeeinflusst, weshalb sie
für eine weitgehende
Standardisierung zugänglich
sind. Sie müssen
nur ein einziges Mal erstellt und geprüft werden. Dies hat zur Folge,
dass Entwicklungskosten sowie Garantie- und Kulanzkosten sinken,
sich die Zeitdauern für
Weiterentwicklungen verkürzen
und der Produktreifegrad erheblich gesteigert wird.
-
Vorteilhafterweise
wird die Ablaufsteuerung nicht nur über die Parameterdatenbank,
sondern auch über
eine Grenzwertedatenbank und insbesondere über Plug-In-Module flexibel
an die individuellen Bedingungen eines Einzelfalls innerhalb einer
Domäne
angepasst. So ist es zum Beispiel möglich, über ein individuell ausgewähltes Plug-In-Modul
eine gewünschte
Funktionserweiterung für
die Ablaufsteuerung zu realisieren, ohne dass die Software der standardisierten
Ablaufsteuerung dafür
verändert
werden müsste.
-
Vorteilhafterweise
läuft die
Ablaufsteuerung in einer normalisierten Umgebung. Die Kapselung wird
softwaremäßig durch
Linearisierungs-/Normalisierungsanteile im Eingangspfad der Ablaufsteuerung
und durch einen Denormalisierungsanteil im Ausgangspfad der Ablaufsteuerung
realisiert. Der Linearisierungs-/Normalisierungsanteil sowie der Denormalisierungsanteil
sind vorzugsweise standardisiert und wo immer möglich domänenübergreifend sonst domänenspezifisch
ausgebildet. Die genannten Softwareanteile bewirken eine Kalibration
der angeschlossenen Peripherieelemente und unterstützen so
auch einen Anschluss von weniger genauen (preiswerten) Peripherieelementen
an das Steuergerät.
Weil die Ablaufsteuerung in einer normalisierten Umgebung läuft, kann
ihre Systemstruktur vereinfacht beziehungsweise weiter standardisiert
werden. Die Normalisierung und Standardisierung der Ablaufsteuerung
macht diese unabhängig
von den Typen und den Herstellern der angeschlossenen Peripherieelemente
und gibt dem Anwender die Freiheit, jederzeit Lieferant und Typ
eines Peripherieelementes wechseln zu können, ohne dass dafür die standardisierte
Ablaufsteuerung, der Linearisierungs-/Normalisierungsanteil, der
Denormalisierungsanteil oder der standardisierte Domain-Controller
verändert
werden müsste.
Es ist in diesen Fällen
lediglich eine entsprechende Anpassung beziehungsweise Änderung
der dem Linearisierungs-/Normalisierungsanteil und dem Denormalisierungsanteil
von einer Konfigurationsdatenbank zuzuführenden vorrichtungsbeziehungsweise
funktionsspezifischen Daten erforderlich.
-
Aus
Sicherheitsgründen
ist es weiterhin vorteilhaft, wenn das Softwarepaket einen Diagnose- und
Fehlererkennungsanteil aufweist und/oder zumindest teilweise redundant
ausgebildet ist. Aus den gleichen Gründen kann auch der Domain-Controller zumindest
teilweise redundant ausgebildet sein.
-
Die
oben genannte Aufgabe der Erfindung wird weiterhin durch ein Netzwerk
zum Steuern einer Vielzahl von Vorrichtungen, insbesondere eines Kraftfahrzeugs
gelöst,
wobei in diesem Netzwerk mindestens zwei der beschriebenen erfindungsgemäßen Steuergeräte zwecks
Datenaustausch miteinander verknüpft
sind. Dabei ist es besonders vorteilhaft, wenn die Domain-Controller
verschiedener Domänen über ein
Gateway miteinander gekoppelt sind, weil ein solches Gateway neben
einer reinen Multiplexer-Funktion
auch – falls
erforderlich – eine Protokollumsetzung
realisieren kann. Dieses Gateway kann auch Bestandteil eines der
Steuergeräte sein.
-
Schließlich wird
die oben genannte Aufgabe auch durch ein Verfahren zum Ausrüsten eines
Fahrzeugs mit mindestens einem der beanspruchten Steuergeräte oder
mindestens einem der beanspruchten Netzwerke gelöst. Dabei werden vorteilhafterweise
bereits während
der Produktion des Fahrzeugs die individuellen Vorrichtungen des
Fahrzeugs erfasst, welche später über das
Steuergerät angesteuert
werden sollen. Die Software des Steuergerätes kann dann am Ende des Produktionsprozesses
für die
jeweils erfassten Vorrichtungen zusammengestellt und auf das Steuergerät beziehungsweise
den standardisierten Domain-Controller eingespielt werden.
-
Das
Zuordnen einer spezifischen Nummer für jedes eingespielte Softwarepaket,
fallweise auch je Softwaremodul, bietet den Vorteil, dass dieses
eindeutig identifizierbar ist. So ist der Hersteller immer in der
Lage, von jedem Fahrzeug den aktuell eingespielten Softwarestand
zu bestimmen. Zur Durchführung
eines Software-Updates, zum Beispiel in Werkstätten, wird diese Nummer dann
in eine zentrale Datenbank eingelesen und der durch sie repräsentierte Softwarestand
mit dem neuesten verfügbaren
Softwarestand verglichen. Bei dem Software-Update wird dann die
Datenhistorie für
jedes Software-Paket fortgeschrieben. Mit Hilfe dieser Zuordnungen
können die
Softwarestände
von Fahrzeugen gezielt bestimmt werden.
-
Weitere
vorteilhafte Ausgestaltungen des Steuergerätes, des Netzwerks und des
Verfahrens sind Gegenstand der abhängigen Ansprüche.
-
Die
Erfindung wird nachfolgend detailliert in Form von Ausführungsbeispielen
unter Bezugnahme auf die beigefügten
Figuren beschrieben, wobei
-
1 die Ansteuerung einer
Vorrichtung durch eine erfindungsgemäße Steuereinrichtung über ein
Peripherieelement;
-
2 den Aufbau der erfindungsgemäßen Steuereinrichtung;
-
3 den Aufbau eines erfindungsgemäßen Softwarepaketes;
und
-
4 ein erfindungsgemäßes Verfahren veranschaulicht.
-
In 1 ist zu erkennen, wie eine
Vorrichtung 300 über
eine erfindungsgemäß ausgebildete Steuereinrichtung 100 eines
Steuergerätes
angesteuert wird. Konkret erfolgt die Ansteuerung ausgehend von
der Steuereinrichtung 100 zunächst über einen Datenbus 400,
welcher die Steuereinrichtung 100 mit einer Peripherieeinrichtung,
in der Regel ein Sensor 200 oder ein Aktor 200', verbindet.
Die Peripherieeinrichtung 200, 200' steuert dann im Ansprechen auf
Befehle eines in 1 nicht
gezeigten Softwarepaketes des Steuergerätes die Vorrichtung 300 direkt
an oder empfängt
Sensorsignale von ihr. Bei der Vorrichtung 300 kann es
sich zum Beispiel um den Motor, das Getriebe, einen Sitz, ein Schließsystem
oder eine Kommunikationseinrichtung, wie eine HiFi-Anlage, einen
Personal Computer oder ein Navigationssystem etc. eines Fahrzeugs
handeln.
-
In 2 ist der Aufbau der Hardware
des erfindungsgemäßen Steuergerätes, insbesondere
von dessen Steuereinrichtung 100 veranschaulicht. Die Steuereinrichtung 100 ist
vorzugsweise als Mikrocontroller ausgebildet und umfasst deshalb
in der Regel auch die typischen Einrichtungen eines Mikrocontrollers,
insbesondere einen Mikroprozessor 110, eine Eingangs-/Ausgangseinrichtung 140 und
eine Speichereinrichtung 150. Die Eingangs-/Ausgangseinrichtung 140 ist
vorzugsweise als Busschnittstelle, insbesondere zum Anschluss der
Peripherieelemente 200, 200' über einen standardisierten
LIN-Bus oder SAE
J180-Bus ausgebildet.
-
Neben
den typischen Einrichtungen eines Mikrocontrollers umfasst die Steuereinrichtung 100 auch
weitere Einrichtungen, wie beispielsweise eine Sicherheitseinrichtung 120 und
eine Energiespareinrichtung 130. Die Sicherheitseinrichtung 120 dient zum
Schutz des Controllers gegen unberechtigten Zugriff und unerwünschte Manipulation.
Die Energiespareinrichtung 130 dient dazu, die elektrische
Leistungsaufnahme der Steuereinrichtung 100 bedarfsorientiert
zu steuern. Aus Sicherheitsgründen
ist es vorteilhaft, wenn zumindest einzelne der Einrichtungen des
Domain-Controllers redundant ausgebildet sind.
-
Erfindungsgemäß ist die
in 2 gezeigte Steuereinrichtung
zumindest teilweise domänenspezifisch,
das heißt
als Domain-Controller
ausgebildet. Dies bedeutet, dass sie ganz gezielt im Hinblick auf eine
spezielle Klasse beziehungsweise Gruppe von identischen oder zumindest ähnlichen
Anforderungen an das Steuergerät
optimiert ist. Diese zumindest ähnlichen
Anforderungen an das Steuergerät werden
von den anzusteuernden Vorrichtungen 300 definiert. Dementsprechend
wird das Steuergerät vorzugsweise
nur zur Ansteuerung solcher Vorrichtungen eingesetzt, welche in
ihren Anforderungen an das Steuergerät zumindest annähernd übereinstimmen.
-
Die
domänenspezifische
Ausbildung des Domain-Controllers bedeutet insbesondere, dass dieser hinsichtlich
seines Echtzeitverhaltens, seiner Sicherheitsvorkehrungen oder hinsichtlich
seiner Funktionalitäten
wie Temperaturstabilität
oder Datendurchsatz im Hinblick auf die Anforderungen der von dem Steuergerät anzusteuernden
Vorrichtungen optimiert ist. Die Optimierung kann auch darin bestehen,
dass, je nach Anwendungsfall, einzelne der normalerweise üblichen
und oben genannten Einrichtungen 110...150 des Domain-Controllers
weggelassen werden, wenn deren Funktion nicht benötigt wird.
-
Ungeachtet
seiner domänenspezifischen Ausbildung
ist es vorteilhaft, wenn der Domain-Controller 100 hinsichtlich
seiner Verarbeitungsleistung und/oder der Speichergröße seiner
Speichereinrichtung 150 skalierbar ist. Auch diese mögliche Ausbildung
leistet einen wesentlichen Beitrag für eine weitere Standardisierung
des Domain-Controllers. Sie gewährleistet,
dass ein- und dieselbe Domain-Controller-Architektur, welche hinsichtlich
der oben genannten Anforderungen für einen speziellen Anwendungsfall
optimiert ist, nicht verändert
zu werden braucht, nur weil einzelne Anwendungsfälle mit denselben domänenspezifischen
Anforderungen an das Steuergerät
eine größere oder
kleinere Verarbeitungsleistung und/oder Speichergröße benötigen.
-
Die
physikalischen Größen, hinsichtlich
derer das Steuergerät
skalierbar ist, sind von den domänenspezifischen
Anforderungen an das Steuergerät
zu unterscheiden. Während
die skalierbaren Größen Anforderungen
an das Steuergerät
als Ganzes repräsentieren,
wobei insbesondere davon ausgegangen wird, dass das Steuergerät als Ganzes
eine Vielzahl von Vorrichtungen ansteuert, repräsentieren die domänenspezifischen
Anforderungen immer nur die Anforderungen an das Steuergerät aus Sicht
einzelner anzusteuernder Vorrichtungen. Wenn von einem Steuergerät also mehrere
Vorrichtungen quasi gleichzeitig angesteuert werden, kann dessen
erforderliche Verarbeitungsleistung oder Speicherkapazität um ein
Mehrfaches höher
liegen als eine entsprechende domänenspezifische Anforderung
einzelner Vorrichtung dies verlangen würde.
-
So
ist es kein Widerspruch, wenn ein und derselbe Domain-Controller zum einen
ein bestimmtes Echtzeitverhalten ermöglicht, was als domänenspezifische
Anforderung von einzelnen Vorrichtungen an ihn gestellt wird, und
zum anderen hinsichtlich seiner Verarbeitungsleistung skalierbar
ist. Das Echtzeitverhalten beschreibt zum Beispiel die Leistung des
Domain-Controllers, welche zur Verarbeitung von Daten eines Zylinders
(Vorrichtung) einer Brennkraftmaschine in Echtzeit erforderlich
ist. Davon unabhängig
kann die erforderliche Gesamt-Verarbeitungsleistung des Domain-Controllers
wesentlich höher
anzusetzen sein. Dies gilt insbesondere dann, wenn nicht nur die
Daten von einem Zylinder, sondern die Daten von mehreren Zylindern
der Brennkraftmaschine in Echtzeit verarbeitet werden sollen. Die
von dem Domain-Controller verlangte Verarbeitungsleistung liegt
dann um ein Mehrfaches höher, als
in Bezug auf das Echtzeitverhalten jedes einzelnen Zylinders gefordert
wird.
-
Grundsätzlich umfasst
ein Steuergerät
lediglich einen Domain-Controller.
Es ist jedoch auch denkbar, dass ein Steuergerät mehrere Domain-Controller
aufweist, welche jeweils unterschiedliche, ein und derselben Domain
zugeordnete Anforderungen realisieren und zum Zwecke einer umfassenden
Bereitstellung von Funktionen durch das Steuergerät untereinander,
vorzugsweise über
einen standarisierten Bus, wie z.B. den CAN-Bus, miteinander vernetzt sind.
-
Mehrere
Steuergeräte
beziehungsweise deren jeweilige Domain-Controller können auch dann, wenn sie jeweils
unterschiedlichen Domains zugeordnet sind, miteinander vernetzt
sein. Die Vernetzung der Domain-Controller untereinander erfolgt dann
vorzugsweise über
Gateways, wobei letztere neben einer Multiplexerfunktion zusätzlich noch
eine eventuell erforderliche Protokollumsetzung zwischen verschiedenen
Domain-Controllern ermöglichen
können.
-
3 zeigt die erfindungsgemäße Struktur des
Softwarepaketes 500 für
das Steuergerät.
Kernstück
des Softwarepaketes ist eine domänenspezifisch
ausgebildete normierte Ablaufsteuerung 510. Sie ist im
Wesentlichen wie eine von Neumann'sche Zustandsmaschine ausgebildet. Sie
erfasst physikalische Eingangsgrößen, welche
ihr über
direkt an das Steuergerät
angeschlossene Sensoreinheiten 230 oder über eine
Busanbindung 400, zum Beispiel in Form einer CAN-Bus- oder einer LIN-Bus-
oder einer SAE J1850 Bus-Anbindung zugeführt werden. Sie empfängt diese
Eingangsgrößen in Form
des Eingangsmusters und vergleicht dieses Eingangsmuster mit einem
vorgegebenen Bedingungsmuster, welches einem Zustand, in dem sich
die Ablaufsteuerung 510 aktuell befindet, zugeordnet ist.
Dieses Bedingungsmuster der Ablaufsteuerung 510 wird individuell
für die
jeweils an das Steuergerät
angeschlossene Konfiguration der Vorrichtungen 300 von
einer Parameterdatenbank 520 zur Verfügung gestellt. Aufgrund des
Ergebnisses dieses Vergleiches entscheidet die Ablaufsteuerung 510 dann,
ob sie in ihrem aktuellen Zustand verbleiben oder in einen neuen
Zustand wechseln soll.
-
In
Abhängigkeit
davon löst
die Ablaufsteuerung 510 bestimmte Ereignisse aus. Ein Ereignis, welches
ausgelöst
werden kann, ist zum Beispiel die Aktivierung eines ausgewählten geeigneten Plug-In-Moduls 540-1...3.
Ein solches Plug-In-Modul bietet die Möglichkeit einer Funktionserweiterung
für die
Ablaufsteuerung während
diese in einem bestimmten Zustand ist. Diese Funktionserweiterung kann
zum Beispiel in einer Aufbereitung oder Filterung von Daten oder
in der Bereitstellung eines Regelalgorithmus für die Ablaufsteuerung bestehen. Insbesondere
die Plug-In-Module 540-4...-6 im Ausgangspfad
der Ablaufsteuerung 510 können auch eine streaming machine
und/oder einen Pre- oder Postprozessor in Software oder Hardware
oder einer Kombination aus Sofware und Hardware bereitstellen. Entsprechendes
ist auch für
den Eingangspfad möglich
(hier nicht bildlich dargestellt).
-
Die
Plug-In-Module 540-1...-6 werden im Bedarfsfalle über eine
standardisierte Schnittstelle von der Ablaufsteuerung 510 aktiviert
und mit Daten versorgt oder deaktiviert. Es besteht jedoch auch
die Möglichkeit,
dass die Plug-In-Module 540-1...-3 direkt, das heißt unter
Umgehung der Ablaufsteuerung 510, von geeigneten Eingangsgrößen, bereitgestellt von
der Sensoreinheit 200 über
den Bus 400 oder von einem Sensor direkt über den
Sensoreingang 240, aktiviert werden. Danach ist entweder
eine Interaktion mit der Ablaufsteuerung 510 oder auch
eine direkte Ausgabe von Daten an die Aktoreinheit 200' über den
Bus 400 möglich
oder direkt an einen Aktor über
den Treiberausgang 240'.
Die Plug-In-Module 540-1...-6 können sowohl
software- wie auch hardwaremäßig ausgebildet
sein.
-
Die
soeben in abstrakter Form beschriebene Arbeitsweise der Ablaufsteuerung 510 wird
nachfolgend anhand eines Beispiels veranschaulicht. Dazu sei angenommen,
dass das Steuergerät
zur Ansteuerung einer Sitzklimatisierung als Vorrichtung 300 eingesetzt
werden soll. Über
geeignete Temperatursensoren als Sensoreinheit 230 des
busfähigen
Peripherieelementes 200 wird eine aktuelle Temperatur des
Sitzes zunächst
erfasst (siehe 1). Die
erfasste Temperatur wird dann von einer Signalaufbereitungseinrichtung 220 innerhalb
des Peripherieelementes 200 auf das Datenformat eines an
das Peripherieelement angeschlossenen Datenbusses 400, zum
Beispiel den LIN-Bus oder SAE-J1850 Bus, umgesetzt und von einer
Busschnittstelle 210 über
den LIN-Bus oder SAE J1850-Bus an den Domain-Controller 100 und
die Ablaufsteuerung 510 übermittelt. Es wird weiterhin
angenommen, dass sich die Ablaufsteuerung 510 zu diesem
Zeitpunkt in einem Zustand "Sitztemperatur-Überwachung" befindet. Die Ablaufsteuerung 510 vergleicht
dann die Ist-Temperatur des Sitzes als Eingangsgröße beziehungsweise
als Eingangsmuster mit einem vorgegebenen Bedingungsmuster, welches
zum Beispiel vorgibt, dass der aktuelle Zustand der Ablaufsteuerung 510" Sitztemperatur-Überwachung" nur so lange beizubehalten ist,
wie die Sitztemperatur in einem Bereich von 18 – 22 ° liegt. Liegt die Ist-Temperatur
des Sitzes zum Beispiel bei 25 ° C,
also außerhalb
des durch das Bedingungsmuster vorgegebenen Bereiches, so wechselt
die Ablaufsteuerung in einen neuen Zustand "Sitzkühlen". Die Ablaufsteuerung 510 aktiviert
dann im Ansprechen auf das Ergebnis dieses Vergleiches über den
Bus 400 eine Kühleinrichtung
als Peripherieelement 200' zum
Kühlen
des Sitzes von 25° C herunter
in den von dem Bedingungsmuster vorgegebenen Bereich. Die Kühleinrichtung
als Peripherieelement 200' umfasst
eine Busschnittstelle 210' zum Empfangen
der Daten von dem Bus 400, eine Treibereinrichtung 220' und eine hier
als Kühleinheit
ausgebildete Aktoreinheit 230'. Parallel zu der Aktivierung der
Kühleinrichtung 200' kann die Ablaufsteuerung 510 zum
Beispiel ein ihr zugeordnetes Plug-In-Modul 540-1 aktivieren,
welches einen Regelalgorithmus bereitstellt, der vorgibt, mit welchem
zeitlichen Verlauf die Temperatur des Sitzes 300 mit Hilfe
der Kühleinrichtung 200' heruntergefahren
werden soll.
-
Neben
einer Parameterdatenbank 520, welche grundsätzlich die
Bedingungsmuster für
alle Zustände
bereitstellt, kann der nicht-domänenspezifische
Teil des Softwarepaketes 500 auch eine Grenzwertedatenbank 595 vorsehen,
welche spezielle Bedingungsmuster für die Ablaufsteuerung 510 bereitstellt.
Diese speziellen Bedingungsmuster geben vor, was zu tun ist, wenn
die der Ablaufsteuerung 510 zugeführten Eingangsgrößen bestimmte
Grenzwerte unter- oder überschreiten.
Sie kann zum Beispiel auch einen Fail-safe-Zustand für die Ablaufsteuerung 510 vorgeben,
welcher dann einzunehmen ist, wenn der Ablaufsteuerung aufgrund
der ihr zugeführten Eingangsdaten
bekannt wird, dass von der Vorrichtung 300 möglicherweise
eine Gefahr ausgeht. In diesem Fail-safe-Zustand veranlasst die
Ablaufsteuerung 510 durch Ausgabe geeigneter Ausgangsgrößen vorzugsweise
ein Abschalten der Vorrichtung 300, von welcher die Gefahr
auszugehen droht.
-
Vorteilhafterweise
arbeitet die Ablaufsteuerung 510 in einer normalisierten
Umgebung; dies ist eine wichtige Voraussetzung für eine weitreichende Standardisierung
der Ablaufsteuerung. Zu diesem Zweck ist der Ablaufsteuerung 510 auf
ihrer Eingangsseite ein softwaremäßiger, ebenfalls domänenspezifischer
oder domänenübegreifender
Linearisierung-/Normalisierungsanteil 550 vorgeschaltet,
zum Linearisieren und/oder Normalisieren von direkt oder über einen
Bus 400 zugeführten
Eingangsgrößen. Spiegelbildlich
dazu ist auf der Ausgangsseite der Ablaufsteuerung 510 ein
domänenspezifisch oder domänenübegreifend
ausgebildeter Denormalisierungsanteil 560 vorgesehen zum
Anpassen der Ausgangsgrößen der
Ablaufsteuerung 510 an diejenigen physikalischen Einheiten,
die von dem jeweils angesteuerten Peripherieelement 200, 200' verwendet werden.
Auf diese Weise ist es möglich,
dass die Ablaufsteuerung 510 abstrakt, das heißt unabhängig von
speziellen von den verwendeten/angeschlossenen Peripherieelementen
und insbesondere unabhängig
von den von den Peripherieelementen verwendeten physikalischen Einheiten
ausgebildet wird, wodurch sie für
eine Standardisierung besonders geeignet wird.
-
Sowohl
der Linearisierungs-/Normalisierungsanteil 550 wie auch
der Denormalisierungsanteil 560 stellen lediglich geeignete
Umrechnungsalgorithmen bereit, weshalb sie standardisiert und zumindest
teilweise domänenübergreifend
ausgebildet werden können.
Sie müssen
jedoch individuell an die jeweils angeschlossenen Peripherieelemente
angepasst werden. Zu diesem Zweck werden die genannten Softwareanteile 550 und 560 aus
jeweils zugeordneten, vorzugsweise flashbaren, Kalibrationsdatenbanken 555, 565 mit
jeweils für
die angeschlossenen Peripherieelemente geeigneten Daten, insbesondere
zur Kennlinienadaption gespeist.
-
Weiterhin
kann das Softwarepaket 500 einen Diagnose- und Fehlererkennungsanteil 590 umfassen,
welcher ein Erkennen und Beheben von Fehlern in der Funktionsweise
des domänenspezifischen
Anteils des Softwarepaketes ermöglicht.
-
Dieser
Diagnose- und Fehlererkennungsanteil 590 wird vorteilhafterweise
von einer Konfigurationsdatenbank 600 mit geeigneten Daten
oder Algorithmen versorgt und hinsichtlich seiner aktuellen Software-Version überwacht.
-
Die
Implementierung des bisher beschriebenen Steuergerätes für eine Anwendung
in einem Fahrzeug, insbesondere in einem Kraftfahrzeug, erfolgt
vorzugsweise im Rahmen des Produktionsprozesses des Kraftfahrzeugs.
Ein derartiger Implementierungsvorgang ist in 4 schematisch dargestellt. Nach einem
Startschritt S0 umfasst dieser Implementierungsvorgang zunächst einen
Schritt S1, bei dem alle Vorrichtungen eines spezifischen Fahrzeugs
ermittelt werden, welche über
ein Steuergerät oder
ein Netzwerk der oben beschriebenen Art angesteuert werden sollen.
-
In
einem nachfolgenden Verfahrensschritt S2 werden die zuvor ermittelten
Vorrichtungen des Fahrzeugs im Hinblick auf ihre jeweiligen Anforderungen
an ein Steuergerät
untersucht oder abgefragt und einer Domäne zugeordnet. Die Steuergeräte umfassen
jeweils einen Domain-Controller 100 und ein Softwarepaket
mit den domänenspezifischen
Softwareanteilen 510, 550 und 560.
-
Neben
diesen domänenspezifischen
Anteilen umfassen die Softwarepakete 500 für die Steuergeräte auch – wie oben
bereits erwähnt – nicht-domänenspezifische
Anteile, insbesondere die Parameter und/oder Grenzwertedatenbank 520, 595 oder Plug-Ins
etc. Deren Inhalte müssen
in Form von Daten je nach Art der durch das Steuergerät zu realisierenden
Funktionen beziehungsweise der angeschlossenen Peripherieelemente
und Vorrichtungen individuell zusammengestellt werden (Verfahrensschritt 3).
-
Das
Zusammenstellen des Softwarepaketes für ein individuelles Steuergerät umfasst
im Einzelnen das Laden von nichtfahrzeugspezifischer Software in
Form eines Betriebssystems und der Ablaufsteuerung, das Laden von
fahrzeugspezifischen Funktions- und Diagnoseparameterdaten, von Adressdaten,
Kalibrationsdaten und Grenzwertdaten für die jeweils konkret verwendeten
Peripherieelemente, das Laden von Bedingungsmustern und Plug-In-Funktionalitäten sowie
das Laden von spezifischen Treibern für das Steuergerät. Das Laden
der Kalibrationsdaten für
die Linearisierungs-/Normalisierungs- und Denormalisierungsanteile 550, 560 erfolgt
aus den diesen Anteilen zugeordneten Kalibrationsdatenbanken 555, 565 und
das Laden der übrigen
Daten erfolgt aus der Konfigurationsdatenbank 600.
-
Vorteilhafterweise
senden die über
einen Bus angeschlossenen Sensoren und Aktoren eine Typkennung,
wenn der Domain Controller diese anfordert. Damit wird der Vorgang
der Paarung von Sensor/Aktor zu einem jeweilig passenden Kalibrationsdatensatz
automatisiert. Konfigurationsfehler werden so in der Produktion
oder bei einem eventuell auftretenden Servicefall unterbunden.
-
Grundsätzlich kann
dann bereits das zusammengestellte Softwarepaket auf den jeweiligen
Domain-Controller des Steuergerätes
oder des Netzwerkes eingespielt werden (Verfahrensschritt S4). Damit
wäre das
Verfahren zur Implementierung eines individuellen Steuergerätes gemäß Verfahrensschritt S5
beendet.
-
Die
Konfigurationsdatenbank 600 kann weiterhin ausgebildet
sein zum Verwalten der Versionen von verschiedenen verwendeten Datenbanken
und Softwareanteilen in dem Softwarepaket des Steuergerätes. Dies
bedeutet insbesondere, dass sie einzelne Softwareanteile nur dann
zum Einspielen auf ein Steuergerät
freigibt, wenn keine Inkompatibilitäten zwischen den unterschiedlichen
Versionen bestehen.
-
Darüber hinaus
kann die Konfigurationsdatenbank 600 ausgebildet sein,
Daten und/oder Algorithmen für
Authentifikationsverfahren, für
Lizenzvergabeverfahren und/oder für Abrechnungsverfahren im Zusammenhang
mit einer Nutzung von insbesondere dem domänenspezifischen Anteil des
Softwarepaktes bereitzustellen. Eine derartige Ausbildung der Konfigurationsdatenbank 600 würde eine
wesentliche Erleichterung und Vereinfachung in der Abwicklung der
Nutzung von Softwarelizenzen für
insbesondere den domänenspezifischen
Anteil des Softwarepaketes bedeuten. In diesem Zusammenhang wäre es von
Vorteil, wenn nach einem vorangegangenen Authentifizierungsschritt
bei einem automatischen Einspielen des Softwarepaketes auf ein Steuergerät gleichzeitig
auch ein Abrechnungsprozess für
das verwendete Softwarepaket, für
den im Rahmen des Authentifizierungsschrittes authentifizierten
Nutzer des Softwarepaketes ausgelöst wird, insbesondere wenn
das Softwarepaket in Lizenz verwendet wird.