WO2005006091A1 - Steuergerät und netzwerk für eine mehrzahl von vorrichtungen - Google Patents

Abstract

Die Erfindung betrifft ein Steuergerät für eine Mehrzahl von Vorrichtungen, insbesondere in einem Kraftfahrzeug. Das Steuergerät umfasst ein Softwarepaket mit einem für eine Domäne spezifischen Anteil (500) and mindestens eine Steuereinrichtung (100) zum Interagieren mit mindestens einer der Vorrichtungen (300) über ein Peripherieelement (200) im Ansprechen auf Befehle des Softwarepakets. Derartige Steuergeräte sind insbesondere im Bereich der Kraftfahrzeugelektronik grundsätzlich bekannt. Sie weisen in ihren bisherigen bekannten Ausgestaltungen jedoch den Nachteil auf, dass sie für eine Standardisierung nur bedingt geeignet sind. Um diesen Nachteil zu überwinden, wird erfindungsgemäss vorgeschlagen, nicht nur die Software, sondern auch die Hardware des Steuergerätes domänenspezifisch auszubilden. Dabei wird eine Domäne als eine Gruppe von zumindest ähnlichen Anforderungen an das Steuergerät, insbesondere hinsichtlich dessen Echtzeitverhalten oder dessen Sicherheitsvorkehrungen definiert.

Description

Titel: Steuergerät und Netzwerk für eine Mehrzahl von Vorrichtungen

Beschreibung

Die Erfindung betrifft ein Steuergerät und ein Netzwerk für eine Mehrzahl von Vorrichtungen, insbesondere in einem Kraftfahrzeug (Kfz) . Darüber hinaus betriff 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-Syste , 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. Nicht-funktionale 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änenspezi ischer 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 vorrichtungs- beziehungsweise 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

Figur 1 die Ansteuerung einer Vorrichtung durch eine erfindungsgemäße Steuereinrichtung über ein Peripherieelement;

Figur 2 den Aufbau der erfindungsgemäßen Steuereinrichtung;

Figur 3 den Aufbau eines erfindungsgemäßen Softwarepaketes; und

Figur 4 ein erfindungsgemäßes Verfahren

veranschaulicht .

In Figur 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 Figur 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 Figur 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 Figur 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 Verarbeitungsieistung 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 Zyiinder, 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.

Figur 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 Busaribindung 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-InModul 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 Figur 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änenubegreifender 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 dσmänenspezifischen Anteils des Softwarepaketes ermöglicht. Dieser Diagnose- und Fehlererkennungsanteil 590 wird vσrteilhafterweise 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 Kraftf hrzeugs. Ein derartiger Implementierungsvorgang ist in Figur 4 schematisch dargestellt. Nach einem Startschritt SO umfasst dieser Implementierungsvorgang zunächst einen Schritt Sl, 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 nicht- fahrzeugspezifischer 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.

Claims

Patentansprüche

1. Steuergerät für eine Mehrzahl von Vorrichtungen (300), insbesondere eines Kfz, umfassend: ein Softwarepaket (500) mit einem für eine Domäne spezifischen Anteil (510, 550, 560); und mindestens eine Steuereinrichtung (100) , insbesondere einen Mikrocontroller, zum Interagieren mit mindestens einer der Vorrichtungen (300) über ein Peripherieelement, insbesondere einen Sensor (200) oder Aktor (200'), im Ansprechen auf Befehle des Softwarepaktes ; dadurch gekennzeichnet, dass die Vorrichtungen (300) zumindest ähnliche Anforderungen an das Steuergerät haben; die Klasse dieser zumindest ähnlichen Anforderungen die Domäne repräsentiert; und die Steuereinrichtung (100) zumindest teilweise für die Domäne spezifisch als Domain-Controller ausgebildet ist.

2. Steuergerät nach Anspruch 1, dadurch gekennzeichnet, dass es sich bei den Anforderungen an das Steuergerät beispielsweise um dessen Echtzeitverhalten, dessen Sicherheit oder dessen Funktionalitäten, wie Temperaturstabilität oder Datendurchsatz, handelt.

3. Steuergerät nach einem der vorangegangenen Ansprüche, dadurch gekennzeichnet, dass der Domain-Controller ein domain-spezifisch ausgebildeter Mikrocontroller ist.

4. Steuergerät nach einem der vorangegangenen Ansprüche, dadurch gekennzeichnet, dass der Domain-Controller eine vorzugsweise domänenspezifisch ausgebildete Sicherheitseinrichtung (120) aufweist zum Schutz des Controllers gegen unberechtigten Zugriff.

5. Steuergerät nach einem der vorangegangenen Ansprüche, dadurch gekennzeichnet, dass der Domain-Controller eine vorzugsweise domänenspezifisch ausgebildete Energiespareinrichtung (130) zum bedarfsabhängigen Beeinflussen der Leistungsaufnahme des Domain- Controllers aufweist.

6. Steuergerät nach einem der vorangegangenen Ansprüche, dadurch gekennzeichnet, dass der Domain-Controller eine Eingangs-/Ausgangseinrichtung (140) , insbesondere Busschnittstelle, aufweist.

7. Steuergerät nach Anspruch 6, dadurch gekennzeichnet, dass das Peripherieelement (200) busfähig ausgebildet ist und über einen Datenbus (400) an die Busschnittstelle (140) des Domain-Controllers angeschlossen ist.

8. Steuergerät nach Anspruch 7, dadurch gekennzeichnet, dass ein busfähiger Sensor als busfähiges Peripherieelement (200) neben einer Sensoreinheit (230) auch eine Busschnittstelle (210) und eine Signalaufbereitungseinrichtung (220) aufweist.

9. Steuergerät nach Anspruch 7 oder 8 , dadurch gekennzeichnet, dass ein busfähiger Aktor als busfahiges Peripherieelement (200') neben einer Aktoreinheit (230') auch eine Busschnittstelle (210') und eine Treibereinrichtung (220 ') aufweist.

10. Steuergerät nach Anspruch 8 oder 9, dadurch gekennzeichnet, dass der busfähige Sensor (200) und/oder der busfähige Aktor (200') zumindest teilweise als Companion-Einheit, vorzugsweise als Companion-Chip, ausgebildet ist.

11. Steuergerät nach einem der Ansprüche 6 bis 10, dadurch gekennzeichnet, dass die Companion-Einheit sich aus ein oder mehreren Intelectual-Property IP-Einheiten zusammensetzt .

12. Steuergerät nach einem der Ansprüche 3 - 11, dadurch gekennzeichnet, dass zumindest eine der Einrichtungen (110...150) des Domain-Controllers als Intellectual Property IP-Einheiten ausgebildet ist.

13. Steuergerät nach einem der Ansprüche 3 - 12, dadurch gekennzeichnet, dass der Domain-Controller (100) - bei unveränderter zumindest teilweiser domain-spezifischer Ausbildung seiner Einrichtungen - hinsichtlich seiner Verarbeitungsleistung und/ oder der Speichergröße seiner Speichereinrichtung (150) skalierbar ist.

14. Steuergerät nach einem der vorangegangen Ansprüche, gekennzeichnet durch eine Mehrzahl von Domain- Controllern, welche untereinander, vorzugsweise über einen lokalen Bus, z.B. den CAN-Bus , miteinander vernetzt sind und jeweils unterschiedliche Aufgaben bei der Ansteuerung der Vorrichtungen übernehmen.

15. Steuergerät nach einem der vorangegangenen Ansprüche, dadurch gekennzeichnet, dass der domänenspezifische Softwareanteil umfasst: eine normierte Ablaufsteuerung (510) zum Erfassen von Eingangsgrößen in Form von Eingangsmustern über die Sensoren (200) , zum Vergleichen der Eingangsmuster mit Bedingungsmustern, welche einem aktuellen Zustand der Ablaufsteuerung zugeordnet sind, zum Entscheiden aufgrund des Vergleiches, ob, und wenn ja, in welchen neuen Zustand die Ablaufsteuerung wechselt und zum Auslösen von Ereignissen im Ansprechen auf das Ergebnis des Vergleiches .

16. Steuergerät nach Anspruch 15, dadurch gekennzeichnet, dass ein nicht-domänenspezifischer Anteil des .Softwarepaketes (500) aufweist: eine Parameterdatenbank (520) zum Bereitstellen der Bedingungsmuster, und/oder eine Grenzwertedatenbank (595) zum Bereitstellen von Bedingungsmustern für Grenzfälle, bei denen die von der Ablaufsteuerung zu verarbeitenden Eingangs- oder Ausgangsgrößen vorgegebene Grenzwerte über- oder unterschreiten und ggf. zum Definieren eines Überganges in einen Fail-safe Zustand für die Ablaufsteuerung (510) .

17. Steuergerät nach Anspruch 16, dadurch gekennzeichnet, dass der nicht-domänenspezifische Softwareanteil weiterhin umfasst: - mindestens ein Plug-In-Modul (540-1... -6) , welches eine Funktionserweiterung für die Ablaufsteuerung (510) über eine standardisierte Schnittstelle bereitstellt und von der Ablaufsteuerung (510) im Ansprechen auf das Ergebnis des Vergleiches aktivierbar oder deaktivierbar ist .

18. Steuergerät nach Anspruch 17, dadurch gekennzeichnet, dass die durch das Plug-In bereitgestellte Funktionserweiterung einen allgemeinen Regelalgorithmus, einen Algorithmus zur Aufbereitung oder Filterung von Daten, die Funktion einer Streaming machine und/oder die Funktion eines Pre- oder Postprozessors umfasst.

19. Steuergerät nach Anspruch 17 oder 18, dadurch gekennzeichnet, dass das Plug-In-Modul software- und/oder hardwaremäßig ausgebildet ist .

20. Steuergerät nach einem der Ansprüche 15 - 19, dadurch gekennzeichnet, dass der domänenspezifische Softwareanteil weiterhin umfasst: einen Linearisierungs-/Normalisierungsanteil (550) zum Linearisieren und/oder Normalisieren von Eingangsgrößen für die Ablaufsteuerung (510) mit Hilfe geeigneter Algorithmen; und einen Denormalisierungsanteil (560) zum Anpassen der Ausgangsgrößen der Ablaufsteuerung an die von dem jeweils angesteuerten Peripherieelemente verwendeten spezifischen physikalischen Einheiten mit Hilfe von Denormalisierungsalgorithmen.

21. Steuergerät nach Anspruch 20, dadurch gekennzeichnet, dass der domänenspezifische Softwareanteil weiterhin umfasst: eine Kalibrationsdatenbank (555, 565) , vorzugsweise flashbar, zum Bereitstellen von jeweils erforderlichen Daten für den Linearisierungs-/Normalisierungs- und Denormalisierungsanteil (550, 560) , je nach Typ/Art der im Einzelfall angeschlossenen Peripherieelemente beziehungsweise Vorrichtungen.

22. Steuergerät nach einem der Ansprüche 16 - 21, dadurch gekennzeichnet, dass der nicht-domänenspezifische Softwareanteil weiterhin umfasst: einen Diagnose- und Fehlererkennungsanteil (590) zum Erkennen und Beheben von Fehlern in der Funktionsweise des domänenspezifischen Anteils (510, 550, 560) der Software .

23. Steuergerät nach einem der vorangegangenen Ansprüche, dadurch gekennzeichnet, dass der domänenspezifische und/oder nicht-domänenspezifische Teil des Softwarepakets oder des Domain-Controllers zumindest teilweise redundant ausgebildet sind.

24. Steuergerät nach einem der vorangegangenen Ansprüche, dadurch gekennzeichnet, dass innerhalb einer Domäne, mehrere Domain-Controller direkt über einen Bus miteinander vernetzt sind.

25. Netzwerk zum Steuern einer Vielzahl von Vorrichtungen, insbesondere eines Kfz, dadurch gekennzeichnet, dass: mindestens zwei Steuergeräte, jeweils ausgebildet gemäß einem der Ansprüche 1 - 24, vorgesehen sind zum Ansteuern der Vorrichtungen, welche zumindest teilweise unterschiedliche Anforderungen an die Steuergeräte haben; die Steuergeräte für unterschiedliche Domänen entsprechend den unterschiedlichen Anforderungen der Vorrichtungen ausgebildet sind; und die Domaincontroller der Steuergeräte vorzugsweise über ein Gateway miteinander vernetzt sind.