-
Die vorliegende Erfindung betrifft ein Steuergerät für ein Kraftfahrzeug mit einer Recheneinheit. Die Erfindung betrifft insbesondere die Systemarchitektur der Recheneinheit.
-
Ein herkömmliches Steuergerät umfasst als Recheneinheit einen Mikroprozessor, auf dem die speziellen für das Steuergerät erforderlichen Anwendungen implementiert sind. Die hierbei verwendete Systemarchitektur hat den großen Nachteil, dass sie nicht wiederverwendbar ist. Sollen Änderungen bei der Funktion des Steuergeräts vorgenommen werden, muss die gesamte Anwendung neu programmiert werden. Außerdem kann die Recheneinheit beziehungsweise das Steuergerät nicht wieder verwendet werden, wenn es für eine andere Hardware benutzt werden soll.
-
Aus der
DE 199 09 157 A1 ist ein Fahrzeuginformationsverarbeitungs- und Fahrzeugsteuersystem bekannt, bei dem miteinander kommunizierende Komponenten jeweils eine Schnittstelle aufweisen, über die Funktionen durch andere Komponenten aufgerufen werden können. Ferner ist eine Konfigurations-Schnittstelle vorgesehen, über die die Komponenten in Abhängigkeit davon konfiguriert werden können, welche weiteren Komponenten vorhanden sind. Insbesondere kann dabei ein hierarchischer Aufbau mit Schichten von Schnittstellen-Komponenten, Anwendungs-Komponenten und dazwischenliegenden Aggregations-Komponenten vorgesehen sein.
-
In der
DE 197 09 318 A1 wird ein Steuerungssystem für ein Fahrzeug vorgeschlagen, bei dem einzelne Komponenten Informationen austauschen, wobei Abfragen verarbeitet werden und die einzelnen Komponenten Untereinheiten auf verschiedenen Detaillierungsebenen umfassen können.
-
Weiterhin beschreibt die
WO 2004/014699 A2 ein Priorisierungsverfahren von Informationsgebern zur koordinierten Antriebsstrangsteuerung für ein Kraftfahrzeug. Dabei ist vorgesehen, dass Aufträge und Anforderungen als Schnittstellen zwischen verschiedenen Komponenten übertragen werden können, wobei Teilsysteme gekapselt werden können, um Schnittstellen unabhängig von der konkreten technischen Ausführungsform der Teilsysteme ausbilden zu können.
-
In der Druckschrift
DE 100 46 986 A1 wird ein Verfahren und eine Vorrichtung zur Steuerung eines Fahrzeugs beschrieben, welche eine symmetrische Strukturierung für kombinierte Antriebe vorsieht.
-
Schließlich wird in der
DE 101 36 258 A1 ein integriertes Fahrzeugsteuersystem zum hybriden Steuern mehrerer an einem Fahrzeug angebrachter Komponenten beschrieben.
-
Es ist die Aufgabe der vorliegenden Erfindung, ein Steuergerät für ein Kraftfahrzeug mit einer Recheneinheit bereit zu stellen, deren Systemarchitektur so technologieunabhängig wie möglich ist. Außerdem sollte die Systemarchitektur so ausgestaltet sein, dass das Steuergerät einfach erweiterbar und wartbar ist und hohen, im Kraftfahrzeugbereich erforderlichen Sicherheitsstandards genügt. Außerdem sollte es robust und einfach konfigurierbar und testbar sein.
-
Diese Aufgabe wird durch ein Steuergerät mit den Merkmalen des Anspruchs 1 gelöst. Vorteilhafte Aus- und Weiterbildungen ergeben sich aus den Unteransprüchen.
-
Bei dem erfindungsgemäßen Steuergerät umfasst die Systemarchitektur der Recheneinheit mehrere Schichten, wobei die Schichten hierarchisch aufgebaut sind und eine Schicht n eine oder mehrere Anwendungs-Schnittstellen (API) zu ihrer nächsthöheren Schicht n+1 und eine oder mehrere Dienste-Schnittstellen (SPI) zu ihrer nächstniedrigeren Schicht n-1 umfasst, so dass eine Schicht nur mit seiner jeweils nächsthöheren und/oder nächstniedrigeren Schicht kommunizieren kann.
-
Durch den Schichtaufbau der Recheneinheit des Steuergeräts kann deren Komplexität erheblich verringert werden. Eine auf dem Steuergerät ablaufende Anwendung kann auf diese Weise in den einzelnen Schichten organisiert werden. Dabei spiegeln die hierarchisch oberen Schichten den Leistungsumfang der Anwendung wieder, die hierarchisch unteren Schichten sind wesentlich generischer. Dies hat zur Folge, dass die hierarchisch unteren Schichten wieder verwendbarer sind. Ihre Funktionen können auch von anderen Anwendungen genutzt werden. Auf diese Weise werden die Schichten weitgehend hersteller-, produkt- und technologieunabhängig. Hierbei kommt den Schnittstellen zwischen den Schichten eine besondere Bedeutung zu. Eine Schicht umfasst eine oder mehrere (öffentliche) Anwendungs-Schnittstellen für die Kommunikation mit der nächsthöheren Schicht. Ferner umfasst jede Schicht die Implementierung ihrer Funktionalität, d.h. ein oder mehrere Dienst-Schnittstellen. Die Anwendungs-Schnittstellen können technologieunabhängig gewählt werden. Auf diese Weise kapselt sich jede Schicht hinsichtlich der Implementierungsdetails der Funktionalität der Schicht von seinen Nachbarschichten ab. Jede Schicht kennt lediglich die Anwendungsschnittstelle der unteren Schicht. Die Dienst-Schnittstelle dieser unteren Schicht, d.h. die konkrete Implementierung der Funktionalität der unteren Schicht kann austauschbar und somit technologieunabhängig sein. Durch die Einführung der Schichtstruktur ist die Recheneinheit des erfindungsgemäßen Steuergeräts außerdem leichter erweiterbar und wartbar. Ferner können Subsysteme leichter ausgetauscht werden.
-
Bei der Kopplung der Schichten der Recheneinheit wurde ein sog. Strict-Layering-Konzept verwirklicht. Jede Schicht kann nur mit seinen hierarchisch nächsten Nachbarn kommunizieren. Dabei wird vorzugsweise eine gerichtete, unidirektionale Beziehung zwischen den Schichten gewählt. Hierbei greift lediglich die höhere Schicht auf die Dienst der unteren Schicht zu. Die untere Schicht kann nicht auf die höhere Schicht zugreifen, sie kann jedoch der höheren Schicht Daten zur Verfügung stellen. Je höher eine Schicht angesiedelt ist, desto mächtiger sind ihre Schnittstellen. Die Methoden oder Anwendungen einer Schnittstelle einer höheren Schicht können eine oder mehrere Methoden der Anwendungen einer darunter liegenden Schicht aufrufen. Die Realisierung des Strict-Layering-Konzepts hilft erheblich bei der Abstraktion der Recheneinheit des Steuergeräts. Die hierarchisch unteren Schichten können nämlich generischer ausgebildet sein und somit für verschiedene Anwendungen verwendbar bleiben.
-
Gemäß einer bevorzugten Ausgestaltung des erfindungsgemäßen Steuergeräts sind von einer Schicht n Aufgaben über ihre Dienste-Schnittstelle an die Anwendungs-Schnittstelle der nächstniedrigeren Schicht n-1 übertragbar und von der niedrigeren Schicht n-1 sind Ergebnisdaten über ihre Anwendungs-Schnittstelle an die Dienste-Schnittstelle der nächsthöheren Schicht n übertragbar.
-
Die Systemarchitektur der Recheneinheit des Steuergeräts umfasst erfindungsgemäß eine Ressource-Schicht, die über ihre Dienste-Schnittstelle auf Hardwarekomponenten und/oder Software-Ressourcen des Fahrzeugs zugreift. Die Ressource-Schicht abstrahiert die in Hardware oder Software verfügbaren Ressourcen des Fahrzeugs. Nur durch diese Schicht ist ein direkter Zugriff auf den nativen Code erlaubt. Die Ressource-Schicht kann somit mit einer Menge von Treibern verglichen werden. Die Schicht ist sehr generisch, so dass sie bei einer Vielzahl von Steuergeräten mit verschiedenen Aufgaben verwendet werden kann. Durch die Ressourceschicht werden die nicht funktionalen Eigenschaften der Treiber, wie zum Beispiel das Parameterformat, das verwendete Protokoll und die Art der Kommunikation, von anderen Funktionalitäten abgekapselt. Die oberen Schichten werden hierdurch von den proprietären und herstellerspezifischen Merkmalen entkoppelt.
-
Des Weiteren weist die Systemarchitektur der Recheneinheit des erfindungsgemäßen Steuergeräts eine Integrations-Schicht auf, welche von Hardware-Komponenten gelieferte Daten aufbereitet und/oder konvertiert. Die Integrations-Schicht kann dabei mehrere Anwendungs-Schnittstellen der Ressource-Schicht bündeln. Die Integrations-Schicht bereitet die generischen und möglicherweise noch hardwarenahen Methoden der Ressource-Schicht für die Schichten hierarchisch oberhalb der Integrations-Schicht auf. Die Funktionalität der Integrations-Schicht kann somit mit einem Adapter verglichen werden, der den höheren Schichten eine objektorientierte Sicht auf die hardwarenahen Schnittstellen der Ressource-Schicht bietet. Mit der Integrations-Schicht können z.B. elementare Datentypen (Byte-Arrays, Strings usw.) in höherwertige Fahrzeugereignisse konvertiert werden.
-
Die Integrations-Schicht bündelt erfindungsgemäß einzelne Anwendungs-Schnittstellen der Ressource-Schicht. Hierdurch kann der nächsthöheren Schicht eine sehr viel einfachere Schnittstelle zu der Hardware des Fahrzeugs bereitgestellt werden.
-
Des Weiteren umfasst die Systemarchitektur der Recheneinheit des erfindungsgemäßen Steuergeräts eine Service-Schicht, die Dienste-Funktionen realisiert. Die Service-Schicht bietet eine serviceorientierte Sicht auf die darunter liegenden Schichten der Recheneinheit. Im Gegensatz zu der Integrations-Schicht bestehen die Anwendungs-Schnittstellen der Service-Schicht aus nur rein fachlichen Methoden. Beim Aufruf dieser Methoden (z.B. Systemdiagnose), weiß die aufrufende Anwendung nicht, welche Ressourcen für die Abbildung der entsprechenden Funktionalität verwendet werden. Hierdurch bleibt die Logik der Anwendung von ihrer technischen Umsetzung getrennt. Diese Trennung ermöglicht es vorteilhafterweise, die Dienste-Schnittstellen der Integrations-Schicht und der Ressource-Schicht sowie ggf. sogar der darunter liegenden Hardware ohne eine Anpassung der Logik der Anwendung, welche diese Schichten nutzt, auszutauschen. Die Trennung der Logik von ihrer technischen Realisierung ermöglicht auch eine voneinander unabhängige Entwicklung der einzelnen Schichten.
-
Schließlich weist die Systemarchitektur der Recheneinheit der erfindungsgemäßen Steuereinheit eine Anwendungs-Schicht auf, die den auf dem Steuergerät ablaufenden Anwendungen Laufzeitumgebungen bereitstellt oder diese Laufzeitumgebungen steuert. Die Anwendungs-Schicht kann insbesondere abgegrenzte Laufzeitumgebungen, wie beispielsweise JAVA®-Sandboxes, bereitstellen. Eine Anwendung des Steuergeräts wird in diesen abgegrenzten Laufzeitumgebungen ausgeführt. Die Abgrenzung der einzelnen Anwendungen voneinander erlaubt die Implementierung von zusätzlichen Diensten, wie Nebenläufigkeit, Sicherheitsdiensten oder Priorisierungen. Hierdurch wird gleichzeitig die Stabilität des Systems erhöht. Auch lassen sich die verfügbaren System-Ressourcen gerechter und insbesondere prioritätsabhängig auf die existierenden Anwendungen verteilen. Die zusätzlichen Dienste sollen nicht in einer Anwendung, sondern in den abgegrenzten Laufzeitumgebungen für die Anwendungen implementiert sein. Hierdurch wird die Wiederverwendung von bereits implementierten Diensten erhöht und andererseits die Komplexität einer Anwendung reduziert.
-
Bei der hierarchischen Struktur der Systemarchitektur der Recheneinheit liegt somit die Integrations-Schicht hierarchisch über der Ressource-Schicht, die Service-Schicht hierarchisch über der Integrations-Schicht und die Anwendungs-Schicht hierarchisch über der Service-Schicht.
-
Im Folgenden wird ein Ausführungsbeispiel des erfindungsgemäßen Steuergeräts mit Bezug zu den Zeichnungen erläutert.
- 1 zeigt schematisch die Systemarchitektur der Recheneinheit des Steuergeräts,
- 2 zeigt ein Diagramm zur Veranschaulichung der Abstraktion und Verfeinerung innerhalb der Schichten,
- 3 zeigt die Ressource-Schicht und die Kopplung mit Hardwarekomponenten und Softwareressourcen des Fahrzeugs,
- 4 zeigt die Kopplung der Integrations-Schicht mit der Ressource-Schicht,
- 5 zeigt die Kopplung der Service-Schicht mit der Integrations-Schicht und der Ressource-Schicht,
- 6 zeigt die Benutzereinheit,
- 7 zeigt die Anwendungs-Schicht und
- 8 zeigt die Architektur der Recheneinheit im Detail zur Veranschaulichung eines Beispiels einer Anwendung.
-
Das Steuergerät ist bei einer Vielzahl von elektronischen Einrichtungen eines Kraftfahrzeugs einsetzbar. Das Steuergerät weist eine Recheneinheit auf, die eine bestimmte Systemarchitektur besitzt. Die spezielle Wahl der Systemarchitektur hilft, die Recheneinheit unabhängig von bestimmten Technologien zu machen. Außerdem wird die Abstraktion des Systems unterstützt. Die Besonderheit der Systemarchitektur liegt darin, dass eine Schichtstruktur gewählt wurde. Die einzelnen Schichten (S1 bis S4) sind eine Abstraktion der konkreten Implementierung der Recheneinheit des Steuergeräts. Die einzelnen Schichten S1 bis S4 können dabei als Softwaremodule in der Recheneinheit verwirklicht werden. Es ist jedoch auch möglich, dass jede Schicht S1 bis S4 als Hardwarekomponente mit einer entsprechenden Schnittstelle zu den beiden Nachbarschichten verwirklicht wird.
-
Neben der Recheneinheit umfasst das Steuergerät Hardwarekomponenten 10 und 30, sowie Anwendungen 20, beispielsweise von Drittanbietern, in deren Struktur nicht eingegriffen werden darf. Sie bilden Softwareressourcen, auf welche die Recheneinheit des Steuergeräts zugreifen kann.
-
Die einzelnen Schichten S1 bis S4 der Recheneinheit sind hierarchisch aufgebaut. Je höher eine Schicht S1 bis S4 in der Hierarchie angeordnet ist, desto abstrakter ist ihre Funktion. Die einzelnen Schichten S1 bis S4 sind voneinander unabhängig, ihre gegenseitige Abhängigkeit wird lediglich durch ihre Schnittstellen gegeben. Diese Schnittstellen definieren die fachliche Funktionalität der Schicht S1 bis S4, d.h. was die Schicht S1 bis S4 leistet. Eine Schnittstelle wird als Anwendungs-Schnittstelle (im Folgenden auch API genannt) bezeichnet. Über diese Anwendungs-Schnittstelle greift eine hierarchisch höhere Schicht auf eine niedrigere Schicht zu und nutzt ihre Funktionalität. Die eigentliche Umsetzung der Funktionalität einer Schicht S1 bis S4 wird durch eine Dienste-Schnittstelle (im Folgenden auch SPI genannt) realisiert. Eine höhere Schicht kann somit auf eine oder mehrere Anwendungs-Schnittstellen einer darunter liegenden Schicht zugreifen und damit ihre Funktionalität nutzen. Die eigentliche Realisierung dieser Funktionalität innerhalb der Schicht S1 bis S4 ist für die darüber liegende Schicht unsichtbar.
-
Im vorliegenden Fall weist die Systemarchitektur zumindest vier Schichten auf, vgl. 1. Die unterste Schicht ist die Ressource-Schicht S1. Darüber liegt die Integrations-Schicht S2. Über der Integrations-Schicht S2 liegt die Service-Schicht S3. Und über der Service-Schicht S3 liegt die Anwendungs-Schicht S4. Innerhalb der Integrations-Schicht S2 und der Service-Schicht S3 sind jeweils Benutzer-Einheiten 130 integriert. Auf der Anwendungs-Schicht S4 laufen verschiedene Anwendungen 200 ab.
-
Bei der Wechselwirkung der Schichten untereinander wird das sog. Strict-Layering-Konzept verwirklicht. Das bedeutet, dass eine Schicht der Hierarchiestufe n mit ihren Dienste-Schnittstellen nur auf Anwendungs-Schnittstellen der nächstniedrigeren Schicht n-1 zugreifen kann und die Anwendungs-Schnittstelle der Schicht n Daten nur der Dienste-Schnittstelle der nächsthöheren Schicht n+1 zur Verfügung stellen kann. Dabei überträgt eine Dienste-Schnittstelle einer höheren Schicht Aufgaben an die nächstniedrigere Schicht und eine niedrigere Schicht überträgt Ergebnisdaten an die nächsthöhere Schicht, ohne Kenntnis von dieser höheren Schicht zu haben. Dabei wird die Abstraktion zu höheren Schichten größer, die Verfeinerung zu höheren Schichten kleiner (s. auch 2).
-
Im Folgenden werden die einzelnen Schichten und ihre Wechselwirkung mit anderen Schichten erläutert:
- 3 zeigt die Ressource-Schicht S1. Die Ressource-Schicht S1 abstrahiert die in Hardware oder Software verfügbaren Ressourcen. Nur in dieser Schicht ist ein direkter Zugriff auf nativen Code, beispielsweise über eine JAVA®-Nativ-Interface (JNI), erlaubt. Ferner können bestehende native Module, wie z.B. Sockets, Files usw., integriert werden, um die Stabilität des Systems zu erhöhen. Dies ist in 3 gezeigt. Im Fahrzeug sind als Hardware beispielsweise ein CAN-Bus 50, ein MOST-Bus 90 und Navigationshardware 70 vorhanden. Diese Hardwarekomponenten geben Daten aus, welche von entsprechenden Anwendungen 40, 60, 80 innerhalb der Ressource-Schicht S1 ausgelesen werden können. Die Ressource-Schicht S1 ist somit mit einer Vielzahl von Treibern vergleichbar. Sie bietet eine generische, einfache, fein granulare und somit hochwiederverwendbare Anwendungs-Schnittstelle.
-
Hierarchisch oberhalb der Ressource-Schicht S1 ist die Integrations-Schicht S2 angeordnet (siehe 4). Die Integrations-Schicht S2 bereitet die generischen und möglicherweise noch hardwarenahen Methoden der Ressource-Schicht S1 für die nächsten Schichten auf. Die Funktionalität dieser Schicht kann somit mit einem Adapter verglichen werden. Hardwarenahe Datentypen der Ressource-Schicht S1 werden hier in Objekte konvertiert. Ferner kann die Integrations-Schicht mehrere Anwendungs-Schnittstellen der Ressource-Schicht S1 bündeln. In 4 ist gezeigt, dass die Anwendungs-Schnittstellen des CAN-Busses 40 und des MOST-Busses 80 zu einem Fahrzeugbus 100 gebündelt werden. Die Dienste-Schnittstelle der Fahrzeugbusanwendung 100 innerhalb der Integrations-Schicht S2 greift auf die Anwendungs-Schnittstellen der Anwendungen 40 und 80 für den CAN-Bus und den MOST-Bus innerhalb der Ressource-Schicht S1 zu. Die Anwendungs-Schnittstelle für den Fahrzeugbus 100 innerhalb der Integrations-Schicht S2 stellt hierarchisch höheren Schichten eine einheitliche Schnittstelle für unterschiedliche Busausprägungen auf Hardwareebene bereit. Gleichermaßen kann die Integrations-Schicht S2 Daten vor dem Verschicken aufbereiten. Beispielsweise kann die CAN-Botschaftlänge vor dem Verschicken errechnet werden. Ferner können technische Signale, die über den CAN-Bus beispielsweise von einem Airbagsensor kommen, in objektorientierte Ereignisse übersetzt werden, um diese höheren Schichten zur Verfügung zu stellen. Des Weiteren kann sich die Integrations-Schicht S2 als technischer Listener bei der Ressource-Schicht S1 anmelden. Dies bedeutet, dass sobald von der Ressource-Schicht S1 bestimmte Daten zur Verfügung gestellt werden, diese von der Integrations-Schicht S2 aufgenommen und für höhere Schichten aufbereitet werden.
-
Hierarchisch oberhalb der Integrations-Schicht S2 liegt die Service-Schicht S3 (siehe 5). Die Service-Schicht S3 bietet eine serviceorientierte Sicht auf die darunter liegenden Schichten der Recheneinheit. Im Gegensatz zu der Integrations-Schicht S2 bestehen die Anwendungs-Schnittstellen der Service-Schicht S3 nur aus rein fachlichen Methoden. Beim Aufruf dieser Methoden (z.B. Diagnose-Funktionalität) weiß eine darüber liegende Schicht nicht, welche Ressourcen für die Abbildung dieser Funktionalität verwendet werden. Somit bleibt die Geschäftslogik der Anwendung von ihrer technischen Umsetzung getrennt. Diese Trennung ermöglicht den Tausch einer Dienste-Schnittstelle der darunter liegenden Integrations-Schicht S2 oder der Ressource-Schicht S1 oder sogar der darunter liegenden Hardware, ohne eine Anpassung der Geschäftslogik der Anwendung, welche die Funktionalitäten dieser darunter liegenden Schichten benutzt. Die Anwendungs-Schnittstelle der Service-Schicht S3 stellt den Anwendungen der darüber liegenden Anwendungs-Schicht S4 seine Dienste zur Verfügung. Diese Dienste der Service-Schicht S3 werden aus den funktionalen Anforderungen des jeweiligen Steuergeräts abgeleitet.
-
Die Service-Schicht S3 kann sich als Listener bei der Integrations-Schicht S2 anmelden. Wird z.B. von der Hardware des Airbags ein Ereignis generiert, wird dieses über den CAN-Bus an die Ressource-Schicht S1 übertragen. Da die Integrations-Schicht S2 für solche Ereignisse als Listener bei der Ressource-Schicht S1 angemeldet ist, wird dieses Airbagereignis erfasst. Die Integrations-Schicht S2 generiert daraus beispielsweise ein JAVA®-Objekt. Da die Service-Schicht S3 als Listener bei der Integrations-Schicht S2 für solche Ereignisse angemeldet ist, wird beispielsweise die Dienste-Schnittstelle (SPI) einer Diagnose 120 auf der Service-Schicht S3 benachrichtigt.
-
In die Integrations-Schicht S2 und die Service-Schicht S3 ist eine Benutzer-Schnittstelle 130 integriert (siehe 6). Die Benutzer-Schnittstelle 130 weist einen Anteil 140 in der Service-Schicht S3 und einen Anteil 150 in der Integrations-Schicht S2 auf. Der Anteil 150 in der Integrations-Schicht ist generischer und verfügt über elementare Benutzerzugriffsfunktionen. Der darüber liegende Teil 140 in der Service-Schicht S3 bietet komfortablere Funktionen für den Umgang mit der Benutzeroberfläche an. Der Anteil 150 in der Integrations-Schicht S2 bietet eine sehr feine und somit auch wiederverwendbare Funktionalität über ihre Anwendungs-Schnittstelle der Dienste-Schnittstelle des Anteils 140 in der Service-Schicht S3 an. Die einfache Struktur und feine Granularität des unteren Anteils 150 sichert der Benutzer-Schnittstelle eine hohe Hardwareunabhängigkeit. Der Anteil 150 der Benutzer-Schnittstelle, der in der Integrations-Schicht S2 liegt, kommuniziert mit der darunter liegenden Hardware mit Hilfe der Ressource-Schicht S1. Neben diesen indirekten Hardwarezugriffen ist die Integrations-Schicht auch für die Bereitstellung von Meta-Daten zur allgemeinen Beschreibung der Leitungsfähigkeit der Hardware zuständig. Hierzu gehören z.B. Auflösung, Farbtiefe, Anzahl und Art der installierten Schriften, Koordinaten des Mittelpunktes der Oberfläche usw. Diese Angaben können von dem darüber liegenden Anteil 140 in der Service-Schicht S3 genutzt werden. Die Benutzer-Schnittstelle 130 ist für die Kommunikation der Recheneinheit mit einem Benutzer zuständig. Auf diese spezielle Schnittstelle 130 wird jedoch nicht direkt zugegriffen, sondern über die darüber liegende Anwendungs-Schicht S4.
-
7 zeigt die über der Service-Schicht S3 liegende Anwendungs-Schicht S4. Die Anwendungs-Schicht S4 stellt den auf dem Steuergerät ablaufenden Anwendungen 200 Laufzeitumgebungen bereit. Außerdem kann die Anwendungs-Schicht S4 solche Laufzeitumgebungen steuern. Diese abgegrenzten Laufzeitumgebungen 160, 170, 180 werden auch als Container bezeichnet. Sie können beispielsweise jeweils durch eine JAVA®-Sandbox realisiert werden. Die Anwendungen 200 können Abfragen für die Fahrzeugdiagnose, Navigationsanwendungen oder beliebige andere Anwendungen, die auf dem jeweiligen Steuergerät ablaufen können, sein.
-
Im Folgenden wird mit Bezug zu 8 die Systemarchitektur der Recheneinheit eines Steuergeräts an Hand einer Anwendung gezeigt, die bestimmte Abläufe auslöst, die bei einer Notfunktion, wie zum Beispiel einer Panne, erfolgen sollen. Der Fahrer des Fahrzeugs kann diese Notfunktion durch einen Knopfdruck signalisieren. Nach diesem Signal werden die Daten des Satellitennavigationssystems (GPS) und die Daten des CAN-Busses zum Beispiel per „short messaging service“ (SMS) an einen Operator verschickt. Nach diesem Vorgang wird eine gewisse Zeit auf einen Rückruf gewartet, ansonsten wird der Operator aktiv von der Telematikeinheit, für die das Steuergerät vorgesehen ist, angerufen.
-
Für die Abbildung dieser Funktionalität ist die Kommunikation mit dem CAN-Bus und möglicherweise auch über die serielle Schnittstelle mit dem GPS-Gerät notwendig. Die Integration dieser Funktionalität wird vollständig mit der Service-Schicht S3 gekapselt.
-
Die Anwendungen, auf welche das Steuergerät zugreift, sind im vorliegenden Fall ein Telekommunikationsmodul (GSM-Modul), der CAN-Bus und das GPS-Gerät. Diese Anwendungen werden als „Native Applications“ 210 bezeichnet. Die Treiber für diese Anwendungen sind beispielsweise in der Programmiersprache C geschrieben. Die „Native Applications“ 210 sind direkt über eine Socket-Schnittstelle 220 ansprechbar. Das Kommunikationsprotokoll hierfür ist sehr einfach. Es werden nur Rohdaten 230 übertragen. Diese Kommunikation findet in der Ressource-Schicht S1 statt. Die Rohdaten 230 werden in Low-Level-Fahrzeugereignisse 204 umgewandelt. An den Socket-Server 250 der Socket-Schnittstelle 220 können sich beliebig viele Zuhörer für den Empfang von Nachrichten anmelden. Diese Aufgabe übernimmt der Connector 260. Der Connector 260 entscheidet mit Hilfe des Protokolls, an welchen Server sich ein Zuhörer anmelden muss. Hierdurch kann der Zuhörer vollständig von der konkreten Hardware entkoppelt werden.
-
An den Low-Level-Fahrzeugereignissen 240 ist im vorliegenden Beispiel eine Implementierung des CAN-Busses interessiert. Die API des CAN-Busses der Ressource-Schicht S1 empfängt somit alle Ereignisse des Socket-Servers 250. Dabei ist zu berücksichtigen, dass der Socket-Server 250 mit vielen nativen Sockets gleichzeitig über unterschiedliche Ports kommunizierten kann. Hier endet nun die Zuständigkeit der Ressource-Schicht S1. Das Low-Level-Fahrzeugereignis 240 wird nicht mehr weiter verarbeitet.
-
Für die weitere Verarbeitung des Low-Level-Fahrzeugereignisses 240 ist der Fahrzeugbus aus der Integrations-Schicht S2 zuständig. Die API dieser Schicht meldet sich beim CAN-Bus der Ressource-Schicht S1 als Zuhörer an. Die SPI des Fahrzeugbusses konvertiert das Low-Level-Fahrzeugereignis in eine Nachricht 280. Zu diesem Zweck wird für den Zuhörer ein Busadapter 270 verwendet. Für die Verteilung der Nachrichten wird ein Nachrichtenbroker 290 verwendet. An diesem können sich Nachrichtenzuhörer für den Empfang von Nachrichten anmelden. Die Konvertierung des Fahrzeugereignisses in eine Nachricht bietet eine weitere Abstraktion von der Hardware des Fahrzeugs. Ferner ermöglicht die Nachricht des Steuergeräts der Telematikeinheit eine Filterfunktionalität der ankommenden Nachrichten. Es werden nur die entsprechenden Nachrichtenzuhörer benachrichtigt.
-
In der nächsthöheren Service-Schicht S3 ist ein Fahrzeugnachrichtenservice 300 vorgesehen. Dieser Fahrzeugnachrichtenservice 300 meldet sich als Nachrichtenzuhörer bei dem Nachrichtenbroker 290 an und empfängt somit die Daten indirekt aus dem CAN-Bus. In der SPI des Fahrzeugnachrichtenservices 300 findet eine „echte“ Transformation der ankommenden Nachrichten statt. Dabei werden die rohen Daten des CAN-Busses in sogenannte fachliche Daten wie Strings konvertiert. Der Fahrzeugnachrichtenservice 300 schickt die transformierten Daten als eine Ereignisnachricht 310 weiter. In dieser Nachricht befindet sich bereits das konvertierte Objekt, welches von dem Empfänger interpretiert werden muss.
-
Bei dem Empfänger handelt es sich schließlich um den Notfunktionsanrufmanager 320, der innerhalb der Anwendungs-Schicht S4 vorgesehen ist. Diese Anwendung 320 ist lediglich an den Daten des CAN-Busses und des GPS-Gerätes interessiert und nicht an ihrer Beschaffung. Der Notfunktionsanrufmanager 320 registriert sich bei dem Nachrichtenbroker 290 für den Empfang von Nachrichten. Genauso zeigt der Notfunktionsanrufmanager Interesse an dem Empfang von Ereignissen, die über eine Benutzerschnittstelle erzeugt werden. Dies ist beispielsweise ein Ereignis, das dem Drücken des Tasters für die Notfunktion zugeordnet ist. Falls dieser Knopf gedrückt werden sollte, wird ein entsprechendes Kommando durch die vorstehend beschriebenen Schichten zu dem CAN-Bus geschickt. Der CAN-Bus antwortet asynchron; die Antwort kommt in Form einer Ereignisnachricht an.
