-
Die
Erfindung betrifft ein Verfahren zur Steuerung von Dienstbelegungen
der Teilnehmer in einem Datenbussystem, wobei ein Ressourcenmanager
und verschiedene den Datenbus nutzende Teilnehmer vorhanden sind,
mindestens ein Teilnehmer Dienste anbietet und andere Teilnehmer
diese Dienste nutzen, wobei der Ressourcenmanager Informationen über die
Art der von den Teilnehmern angebotenen verfügbaren Dienste und Informationen über die
dienstanbietenden Teilnehmer speichert, der Ressourcenmanager einen
Dienst eines anbietenden Teilnehmers, wenn der Dienst frei ist,
freihält und/oder
eine Antwort an einen anfragenden Teilnehmer sendet, so dass der
anfragende Teilnehmer den Dienst des anbietenden Teilnehmers über den
Datenbus nutzen kann.
-
Insbesondere
im Zusammenhang mit Telematik-Systemen werden Ressourcenmanager
verwendet, um die große
Zahl von Diensten und Datenmengen zu steuern. Ein Dienst ist beispielsweise
ein Anwendungsprogramm, insbesondere eine auf einem Steuergerät ablauffähige Software.
Der Dienst wird bevorzugt von anderen Softwareprogrammen oder Diensten
genutzt. Bei komplexen Telematik-Systemen werden Anwendungsprogramme,
die in verschiedenen Telematik-Anwendungen aufgerufen werden, nicht
mehrfach in verschiedenen Komponenten sondern einmal als Dienstprogramm
abgelegt. Dieses Dienstprogramm wird dann beim Ausführen verschiedenster
Programme mehrfach von unterschiedlichen Steuergeräten aufgerufen.
Bei komplexen Telematik-Systemen werden bestimmte Dienste sehr häufig benötigt, so
dass die Ressourcen, d.h. die Dienstangebote verwaltet werden. Dabei
werden Belegungszeiten der Dienste erfasst und bei einer An frage
durch einen Dienstnutzer wird ein Dienst freigehalten und für die Dienstnutzung
vorbereitet.
-
Derartige
Ressourcen-Verwaltungsverfahren werden im Zusammenhang mit Verkehrsmitteln, beispielsweise
Flugzeugen, Kraftfahrzeugen und andere, eingesetzt und sind entweder
zentral in einem Ressourcen-Steuergerät abgelegt oder verteilt in mehreren
Steuergeräten
vorgesehen. Im Zusammenhang mit Kraftfahrzeugen werden sowohl Ressourcen
des Datenbusses selbst, d.h. dessen Belegung und freie Kanäle, als
auch Ressourcen des Telematik-Systems verwaltet, welches in verteilter
Form am Datenbus angeschlossen ist. Im letzteren Fall werden Ressourcen
von Navigationssystemen, Radioempfängern, Fernsehempfängern und
telefongebundenen Diagnose- und Softwaresystemen verwaltet.
-
Derartige
Ressourcen-Verwaltungsverfahren werden im Zusammenhang mit Telematik-Datenbussen
bevorzugt eingesetzt. Ein Ressourcen-Verwaltungssystem kann aber
auch mit herkömmlichen Datenbussen,
beispielsweise einem CAN- oder LIN-Datenbus eingesetzt werden. Zum
besseren Verständnis
der weiteren Beschreibung wird als Beispiel für einen Telematik-Datenbus
der im Kraftfahrzeug eingesetzte MOST-Datenbus kurz beschrieben. Die
Datenübertragung über den
MOST-Datenbus gliedert sich in Frames von 64 Byte Länge. Davon werden
das erste und letzte Byte für
administrative Zwecke auf Busebene verwendet. Die verbleibenden Bytes
werden einem Bereich für
synchrone Kanäle, einem
Bereich für
asynchrone Datenübertragung
und einem Kontrollkanal mit 2 Byte zugeordnet. Über die synchronen Kanäle werden
synchrone Daten beispielsweise Audio- und Video-Daten übertragen. Der asynchrone Bereich
wird für
paketorientierte Datenübertragung
verwendet. Die Kontrollbytes des Kontrollkanals wirken mit anderen
Kontrollbytes der anderen Frames zusammen. Die Kontrollbytes werden ausgewertet,
um Kontrollnachrichten zwischen den Geräten am MOST-Bus auszutauschen.
Die Frames sind zyklisch mit einer Frame-Frequenz wiederkehrende
Nachrichtenblöcke.
Synchrone und asynchrone Be reiche können für die unterschiedlichen Ressourcen
je nach Bedarf verwendet werden. Beispielsweise können synchrone
Kanäle
bei einer Fernsehübertragung
auch gebündelt
werden.
-
Gemäß MOST-Specification
Framework, Kapitel 6.0 „MOST
Frame structure" sind
synchrone Datenkanäle
zur Verbindung von Quelle (CD-Spieler) und Senke (Amplifier) vorgesehen,
solange ein synchroner Kanal offen ist. Die Steuerung der synchronen
und asynchronen Kanäle
läuft über den
Kontrollkanal. Eine Software in einem der Steuergeräte sendet
eine Kontrollnachricht an die beteiligten Geräte, um die Datenquelle mit
der neuen Datensenke zu verbinden. Auch die anderen MOST-Funktionen werden über den
Kontrollkanal angesprochen.
-
Beim
MOST-Datenbus und ähnlichen
Datenbussystemen werden Ressourcenmanager eingesetzt, um alle Ressourcen
des Datenbussystems selbst, d.h. die Verwaltung der synchronen und
asynchronen Kanäle
und deren Seiten, als auch die Ressourcen der über den Datenbus angebotenen
Funktionen zu verwalten. Der Ressourcenmanager kennt alle Ressourcen
des Systems die verwaltet werden sollen. Der Ressourcenmanager ist
die zentrale Verwaltungseinheit in Bezug auf die Ressourcen des
Datenbussystems. Außerdem überwacht
und beobachtet der Ressourcenmanager die aktuelle Ressourcenbenutzung
und kennt die Dienste, welche momentan nicht verwendet werden. Sobald
eine Anwendungsfunktion eine der Ressourcen, bspw. Dienste, Funktionen
oder Initialisierungsparameter, beim Ressourcenmanager aufruft,
erteilt dieser eine Freigabe für
den Dienst, soweit die Verwendung des Dienstes möglich oder gestattet ist. Dabei
werden unter anderem Prioritätslevels
und Dienstzugänglichkeit
berücksichtigt.
Hat die aufrufende Funktion eine geringe Priorität oder ist ein Zugriff auf
den Dienst nicht vorgesehen, so lehnt der Ressourcenmanager den
Zugriff auch ab.
-
Die
DE 196 25 002 A1 offenbart
in Spalte 3, in den Zeilen 9-13
sowie Zeilen 30–57
mehrere Applikationen, die auf ein Ge rät zugreifen können. Dabei können Dienste
einer Software-Applikationen
vorbestimmte Funktionen aufrufen.
-
Die
WO 01/84301 A2 zeigt eine Ressourcenverwaltung von Softwaremodulen
durch einen Ressourcenmanager. Der Ressourcenmanager verwaltet die
Ressourcen mittels Prioritäten.
Es gibt hierbei Warteprozesse für
die einzelnen Dienste.
-
Die
EP 771 098 A2 offenbart
ein Telekommunikationssystem, dessen Verbindungsnetze mittels eines
Ressourcenmanagers einem vorgesehenen Kommunikationsauftrag zugeordnet
werden.
-
Die
DE 100 23 705 A1 beschreibt
ein Verfahren zur Steuerung von Gerätezuordnungen bei einem Anwendungsprozess
im Bereich der Telematik. Die Geräte sind dabei an einem Datenbus
innerhalb eines Verkehrsmittels angeordnet. Beim Starten des Anwendungsprozess
wird dann der Bedarf an Geräten
ermittelt und diese werden dem Anwendungsprozess zugewiesen.
-
Es
ist Aufgabe der vorliegenden Erfindung ein Verfahren zur Steuerung
der Dienstbelegung in einem Datenbussystem vorzusehen, welches bei komplexen
Datenbussystemen mit synchronen und asynchronen Funktionen die Ressourcen,
die Dienstbelegung und/oder die Dienstvergabe steuert.
-
Diese
Aufgabe wird durch die Merkmale des unabhängigen Anspruchs 1 gelöst. Bei
dem erfindungsgemäßen Verfahren
werden die Informationen über
die angebotenen Dienste über
eine einheitliche Schnittstelle von den Teilnehmern am Datenbus
angeboten und eine Änderung
eines Dienstangebotes eines Teilnehmers wird über die einheitliche Schnittstelle
für den
Ressourcenmanager zur Verfügung
gestellt, wobei der Ressourcenmanager die Dienstbelegung aufgrund
einer Prioritätsinformation,
die bspw. in einer Nachricht (Anfrage oder Benachrichtigung) eines
anfragenden Teilnehmers an den Ressourcenmanager übertragen
wird, steuert. Die Prioritätsinformation
muss nicht notwendigerweise mit einer Ressourcenanfrage übermit telt
werden. Eine Applikation kann alternativ auch ihre Ressourcenanfrage
mit einem Applikations-Identifier an den Ressourcenmanager senden,
der Ressourcenmanager sendet eine Anfrage an den Prioritätenmanager,
der den aktuellen Gesamtsystemzustand kennt und aufgrund dessen
der Ressourcenanfrage mittels des Applikations-Identifiers eine
Priorität
zugeordnet wird. Der Prioritätsmanager
teilt dann die Priorität
dem Ressourcenmanager mit und dieser belegt die Dienste entsprechend
den Prioritätsinformationen.
-
Die
einheitliche Schnittstelle ermöglicht
den Datenaustausch zwischen beliebigen Funktionen, die einen Dienst
aufrufen, und dem Ressourcenmanager. Alle Ressourcenanfragen müssen an
die Schnittstelle des Ressourcenmanagers gerichtet werden. Dabei
können
Funktionen über
den Datenbus eine Anfrage an die Schnittstelle des Ressourcenmanagers
richten. Da sämtliche
Anfragen an die Schnittstelle des Ressourcenmanagers gerichtet sind,
kann dieser die Verwendung der Dienste und die Belegungszeit einfach
erfassen. Auf der aktuellen Ressourcenbelegung bzw. aufgrund der
aktuellen Ressourcenanfragen kann der Ressourcenmanager dann entsprechend
eines Freigabeverfahrens entscheiden, ob ein Dienst für eine bestimmte
Funktion erteilt oder verweigert wird, oder ob die Anfrage in eine
Warteschleife eingefügt
wird.
-
Der
Ressourcenmanager muss alle im System vorhandenen Ressourcen kennen.
Um Informationen über
die Ressourcen des Ressourcenmanagers zu haben, wird bei einem Hochlaufen
des Datenbusses jeder Ressourcen anbietende Funktionsblock erfasst
und dabei werden Informationen zusammengestellt, welche Ressourcen
ein Funktionsblock bereitstellen kann. Darüber hinaus kann festgestellt
werden, welche Anfragen und/oder welche zugehörende Priorität für einen
Funktionsblock vorgesehen sind.
-
Jede
Ressource bzw. jeder Dienst muss über einen steuernden Funktionsblock
in einheitlicher Weise dem System zur Verfügung gestellt werden. Für synchrone
Ressourcen weist die Schnittstelle bevorzugt spezielle Interface-Funktionen
auf, die in diesem Zusammenhang genutzt werden sollen.
-
Der
Ressourcenmanager kann die Belegung der Datenkanäle innerhalb eines Frames,
bspw. über den
Dienst „Belegung
des Datenkanals n" steuern. Bspw.
kann der Ressourcenmanager einzelnen synchronen Datenkanälen innerhalb
eines Frames einen oder mehrere diese nutzenden Teilnehmer zuweisen.
-
Die
dienstanbietenden Teilnehmer besitzen eine einheitliche Schnittstelle, über die
die Information zu den Diensten vom Ressourcenmanager oder von den übrigen Teilnehmern
abgefragt werden kann. Die Schnittstelle zwischen dem Datenbus und einem
dienstanbietenden Teilnehmer weist Datenformate für Informationen
auf, die die Anzahl und Art der Dienste angibt. Auch kann die maximale
Anzahl der Dienstnutzer pro Dienst zu einem Zeitpunkt übertragen
werden.
-
Die
Aufgabe wird auch durch die Merkmale des unabhängigen Anspruchs 2 gelöst. Bei
dem erfindungsgemäßen Verfahren
werden die Informationen über
die angebotenen Dienste über
eine einheitliche Schnittstelle von den Teilnehmern am Datenbus angeboten
und eine Änderung
eines Dienstangebotes eines Teilnehmers wird über die einheitliche Schnittstelle
für den
Ressourcenmanager zur Verfügung
gestellt, so dass der Ressourcenmanager Dienste steuert, die Funktionen
der Teilnehmer selbst betreffen.
-
Bei
diesem Ressourcen-Verwaltungsverfahren werden im Gegensatz zum ersten
Verfahren nicht die Kanäle
des Datenbusses und damit verknüpfte Dienste
gesteuert, sondern es werden Dienste einzelner Teilnehmer am Datenbus
gesteuert. Insbesondere werden Dienste eines verteilten Telematik-Systems
gesteuert und dabei insbesondere die Dienste der einzelnen Telematik-Komponenten.
Dabei kann auch die Zuordnung einer Daten-Senke zu einer Daten-Quelle
bezogen auf einen synchronen Datenbus-Kanal verwaltet werden. Es
kann aber auch das Ver fahren gemäß Anspruch
1, d.h. die Verwaltung der Datenbusbezogenen Ressourcen, mit dem
Verfahren gemäß Anspruch
2, d.h. die Verwaltung der Ressourcen der Teilnehmer des Telematik-Systems, kombiniert
werden.
-
Bspw.
kann für
die Funktion „Verstärkerbelegung" gleichzeitig ein
Telefon und ein Radio verbunden werden. Bei einer anderen Weiterbildung
der Erfindung wird der Nachrichtenübertragungsbedarf für jeden
einzelnen Teilnehmer am Datenbus angefragt oder abgeschätzt.
-
Über die
eigentliche Datenbusverwaltungsfunktion hinaus arbeitet der Ressourcenmanager
eng mit Diensten des Telematik-Systems
zusammen. Jede Software, die im Telematik-System aufrufbar ist, d.h.
die von anderen Anwendungsfunktionen aufgerufen werden kann, wird
im Ressourcenmanager gespeichert, so dass im Ressourcenmanager eine
Liste sämtlicher
Dienste des Telematik-Systems vorhanden ist. Wird durch eine Funktion
auf einen Dienst zugegriffen, sammelt der Ressourcenmanager Informationen über diesen
Dienst und stellt dessen Speicherort, beispielsweise auf einem ersten
Steuergerät
an einem bestimmten Speicherplatz, fest. Die synchronen Datenbus-Ressourcen
werden auf eine spezielle Art behandelt. Da im Datenbus selbst meist
Funktionen zum Festlegen oder Verbinden von synchronen Datenkanälen mit
synchronen Ressourcen vorhanden sind, verwendet der Ressourcenmanager
oft die im Datenbussystem schon vorhandenen Funktionen.
-
Der
Ressourcenmanager wird über Änderungen
der Dienste durch die dienstanbietenden Teilnehmer informiert. Dienstanfragende
Teilnehmer richten ihre Anfrage an den Ressourcenmanager. Bei jeder
Anfrage teilen die Teilnehmer die angefragten Ressourcen als evtl.
auch die Priorität
der Anfrage mit. Der Ressourcenmanager entscheidet über die Zuteilung
der angefragten Dienste allein aufgrund der Verfügbarkeit und aufgrund der Priorität der Anfrage.
-
Ein
Ressourcenkonflikt entsteht, wenn eine angefragte Ressource bereits
belegt ist. Der Ressourcenkonflikt wird durch den Ressourcenmanager gelöst. Wenn
die Priorität
der aktuellen Anfrage größer als
die Priorität
des bereits nutzenden Teilnehmers ist, wird die bestehende Belegung
des Dienstes aufgehoben und der Dienst kann durch den Ressourcenmanager
für den
anfragende Teilnehmer belegt werden. Wenn die Priorität der aktuellen
Anfrage kleiner oder gleich der Priorität des bereits nutzenden Teilnehmers
ist, wird die Anfrage des Teilnehmers durch den Ressourcenmanager
zurückgewiesen oder
in die Liste der bereits vorliegenden Anfragen eingereiht. Ein anfragender
Teilnehmer kann angeben ob er bei Belegung des Dienstes in einen
Wartelist aufgenommen werden soll.
-
Jede
Ressource muss von dem ressourcenanbietenden Funktionsblock in einer
einheitlichen Art an der Schnittstelle des Ressourcenmanagers angeboten
werden. Beispielsweise sollten für
synchrone Ressourcen des Datenbusses existierende Schnittstellenfunktionen
verwendet werden. Für
alle anderen Ressourcen können
Funktionen wie ein Ressourcenzähler,
Ressourceninfo, Ressourcenkonflikt, Ressourcen festlegen, Ressourcen
entfernen, und Ressourcenverwendung vorgesehen sein. Der Ressourcenmanager
besitzt einen Fehlerbehandlungsalgorithmus, über den auch Funktionen bzw. Dienstanfragen
bearbeitet werden können,
die in fehlerhafter Weise nicht an die Schnittstelle des Ressourcenmanagers
gerichtet waren. Eine Möglichkeit für eine Fehlerbehandlungsroutine
besteht darin, dass der Ressourcenmanager die Verwendung aller Ressourcen überwacht
und feststellt, ob eine ordnungsgemäße Dienstanfrage dazu vorhanden
ist. Der Ressourcenmanager kann dann fragwürdige Ressourcenbelegungen
sofort stoppen.
-
Es
kann vorgesehen sein, dass der Ressourcenmanager den Nutzer eines
Dienstes nicht kennt, beispielsweise den Teilnehmer der die Ressourcenanfrage
stellt. Dieses Erfordernis ermöglicht
ein flexibles und erweiterbares Ressourcenmanagement. Der Ressourcenmanager
erzeugt aufgrund einer Ressourcenanfra ge eine eindeutige Bezeichnung. Diese
Bezeichnung wird für
eine eindeutige Verknüpfung
eines Dienstes mit einem anfragenden Teilnehmer verwendet. Der Ressourcenmanager
hat üblicherweise
jedoch keine direkte Zuordnung zum realen Teilnehmer, so dass aufgrund
der Informationen des Ressourcenmanagers nicht auf reale Geräte zurückgeschlossen
werden kann. Dies hat den Vorteil, dass es auf dem Telematik-System
eine erhöhte
Datensicherheit gibt. Der Ressourcenmanager muss ressourcennutzende
Applikationen nicht kennen, sie können bspw. nachträglich in
ein System eingebracht werden.
-
Ein
Anwendungsprogramm (Application), das beim Ressourcenmanager nach
Ressourcen bzw. Diensten anfragt, übergibt mit der Anfrage eine Liste
der benötigten
Dienste bzw. Ressourcen und evtl. eine Priorität für jede Anfrage. Aufgrund der
vorhandenen Anfragen vergibt der Ressourcenmanager dann entsprechend
der zugeordneten Prioritäten
die Dienstfreigaben für
die anfragenden Anwendungsprogramme.
-
Der
Ressourcenmanager kann beispielsweise als Funktionsblock implementiert
sein. Im Zusammenhang mit einem MOST-Datenbussystem lässt sich der Ressourcenmanager
als sogenannter FBlock umsetzen. Ein MOST-FBlock kann in jedem Teilnehmer
des MOST-Datenbusses umgesetzt werden. Daher ergibt sich eine sehr
hohe Flexibilität
und vorhandene Werkzeuge zur Erzeugung derartiger FBlock-Funktionen
des MOST können
verwendet werden. Der Ressourcenmanager kann programmierbar sein
und flexibel von einem Teilnehmer auf den anderen verlagert werden.
Es gibt verschiedene Möglichkeiten,
das Verfahren der vorliegenden Erfindung in vorteilhafter Weise
weiterzubilden. Dazu ist einerseits auf die untergeordneten Ansprüche und andererseits
auf die nachfolgende Erläuterung
des erfindungsgemäßen Verfahrens
zu verweisen. In der Zeichnung sind verschiedene Verfahrensabläufe dargestellt.
Es zeigen jeweils in schematischer Darstellung,
-
1 eine
Darstellung des Start-up-Verhaltens des Ressourcenmanagers gemäß des erfindungsgemäßen Verfahrens,
-
2 eine
Darstellung des normalen Betriebsverhaltens des Ressourcenmanagers
nach dem erfindungsgemäßen Verfahren,
-
3 eine
Darstellung der Dienstanfrage und der Ressourcenzuteilung gemäß dem vorliegenden
Verfahren,
-
4 eine
Darstellung der Ressourcenanfrage und des Einreihens der Anfrage,
wenn der Dienst belegt ist,
-
5 eine
Darstellung von zwei gleichzeitigen Ressourcenanfragen und
-
6 eine
Darstellung des Verhaltens des Ressourcenmanagers beim Herunterfahren
der Systemkomponenten gemäß dem Verfahren
der vorliegenden Erfindung.
-
In
der 1 ist ein Verfahren zur Steuerung von Dienstbelegungen
der Teilnehmer in einem Datenbussystem dargestellt. Teilnehmer sind
am Datenbus vorhandene Steuergeräte
oder auf diesen Steuergeräten
ablauffähige
Programme. Dazu zählen
der Ressourcenmanager 1, der Netzwerk-Master 2,
ein Funktionsblock (FBlock) 3 mit synchronen Ressourcen
und ein Funktionsblock (FBlock) 4 mit anderen Ressourcen.
Jeder der Teilnehmer 1–4 bietet
Dienste für
das gesamte Datenbussystem bzw. Telematik-System an und jeder einzelne
Teilnehmer 1–4 kann
Dienste der anderen Teilnehmer 1–4 nutzen. Der Ressourcenmanager 1 speichert
Informationen über
die Art der von den Teilnehmern 1–4 angebotenen Dienste
und Informationen ab und hält
einen Dienst eines anbietenden Teilnehmers frei, wenn dessen Dienst
nutzbar ist. Außerdem
sendet der Ressourcenmanager 1 an einen anfragenden Teilnehmer
eine Antwort, so dass der anfragende Teilnehmer den Dienst des anbietenden
Teilnehmers über
den Datenbus nutzen kann.
-
In 1 ist
das Start-up-Verhalten des Telematik-Systems mit dem Datenbus und
den verschiedenen Teilnehmern dargestellt. In dem Diagramm sind
die verschiedenen Kommunikationsschritte des Ressourcenmanagers 1 mit
den anderen Teilnehmern 2–4 zur Start-up-Zeit
dargestellt. Nachdem der Ressourcenmanager beim Anschalten des Systems mit
Strom versorgt wird, werden auch die übrigen Systeme und Teilnehmer
mit Strom versorgt und die verschiedenen Variablen der Software
entsprechend den Vorgaben initialisiert. Sobald vom Netzwerk-Master 2 über den
Datenbus die Nachricht für eine
abgeschlossene Initialisierung an den Ressourcenmanager 1 übertragen
wird, beginnt der Ressourcenmanager 1 mit der Kommunikation.
Der Ressourcenmanager 1 fragt daraufhin alle über den
Datenbus erhältlichen
Ressourcen ab und speichert verschiedene Informationen zu jeder
Ressource bei sich ab, um eine erfolgreiche Ressourcenverwaltung
für das gesamte
Telematik-System durchführen
zu können. Dabei
werden synchrone Ressourcen, d.h. Ressourcen mit zyklisch wiederkehrenden Übertragungserfordernissen
anders behandelt als die anderen asynchronen Ressourcen. Die Trennung
zwischen synchronen und asynchronen Diensten ist erforderlich, da
die Übertragung über den
Datenbus in verschiedenen Bereichen der Frames erfolgen muss. Beispielsweise
sind für
einen MOST-Datenbus synchrone Zeitschlitze und darauffolgende asynchrone
Bereiche vorgesehen.
-
Bei
dem Start-up-Verfahren für
das Telematik-System soll die erforderliche Start-up-Zeit so kurz wie
möglich
sein. Beispielsweise können
bestimmte Abfragen des Ressourcenmanagers auch zeitgleich oder sofort
aufeinanderfolgend durchgeführt
werden. Ist das Start-up-Verfahren noch nicht abgeschlossen, während von
Teilnehmern 1–4 schon
Dienstanfragen an den Ressourcenmanager erfolgen, werden diese Dienstanfragen
beim Ressourcenmanager 1 zwischengespeichert, um sofort
nach der Start-up-Phase derartige Dienstabfragen bearbeiten zu können. Das
Start-up-Verfahren läuft
folgendermaßen
ab:
Nachdem der Ressourcenmanager 1 bezüglich seiner
Variablen und Objekte initialisiert ist, erwartet er während einer
Kommunikation 5 eine Statusnachricht vom Netzwerk-Master 2.
Der Netzwerk-Master 2 sendet diese Nachricht 5 über den
Datenbus an den Ressourcenmanager 1. Falls der Netzwerk-Master 2 als
Steuergerät
ausgebildet ist und der Ressourcenmanager 1 als ablauffähige Software
darauf vorhanden ist, kann die Kommunikation 5 auch als
Nachricht zwischen zwei Softwaremodulen übertragen werden. Nach dem
Empfang der Nachricht während
der Kommunikation 5 sendet der Ressourcenmanager 1 eine Nachricht
an den Netzwerk-Master 2, um das Zentralregister des Netzwerk-Masters 2 bearbeiten
zu können.
Der Netzwerk-Master 2 überträgt daraufhin eine
Kopie des Zentralregisters an den Ressourcenmanager 1.
Im Zentralregister sind Informationen zu den übrigen Teilnehmern 1–4 und
den anfragenden Funktionen (FBlock) und zu den nutzbaren Diensten abgespeichert.
Bei Änderung
im Telematik-System oder im Datenbus-System überträgt der Netzwerk-Master 2 eine Änderungsnachricht
an den Ressourcenmanager 1, so dass dieser über Funktionsänderungen
oder Dienständerungen
im System informiert ist.
-
Während der
Kommunikation 5 überträgt der Netzwerk-Master 2 aber
auch Informationen über
die zeitliche Abfolge der Datenübertragung über den
Datenbus. Diese sogenannte Boundary-Information gibt beispielsweise an,
in welchen zeitlichen Zusammenhängen
synchrone und asynchrone Bereiche übertragen werden oder in welchen
Speicherbereichen des Netzwerk-Masters 2 die Daten des
Ressourcen-Managers 1 abgespeichert werden.
-
Im
folgenden Verfahrensschritt 6 fragt der Ressourcenmanager 1 alle
Funktionen 3 mit synchronen Ressourcen ab. Die Kommu nikation 6 ermöglicht dem
Ressourcenmanager 1 ein Zusammenführen sämtlicher Informationen über synchrone Ressourcen
innerhalb des Systems. Zunächst
fragt der Ressourcenmanager 1 die Anzahl der synchronen
Quellen und Senken dieser Funktionsblöcke ab. Eine synchrone Quelle
ist beispielsweise eine Funktion die zyklisch wiederkehrende Signale
eines Sensors innerhalb des Datenbus-Systems überträgt und eine synchrone Senke
ist der Empfänger
dieses zyklischen Signals. Nach Abschluss der Kommunikation 6 kennt
der Ressourcenmanager 1 sämtliche synchronen Ressourcen
des Systems und hat die Informationen zu diesen Ressourcen abgespeichert.
Mit speziellen Befehlen und Funktionen können andere Teilnehmer 1–4 Informationen
zu diesen synchronen Ressourcen abfragen. Derartige Funktionen sind
beispielsweise SourceInfo, SinkInfo und SyncDataInfo. Schließlich werden
noch die Zusammenhänge
zwischen den einzelnen Funktionsblöcken beschrieben und es kann
jeder Senke ein entsprechender Quellenfunktionsblock zugeordnet
werden.
-
Während der
Kommunikation 7 fragt der Ressourcenmanager 1 die
Funktionsblöcke 4 mit
den übrigen
Ressourcen ab. Dazu weist der Ressourcenmanager 1 einen
Satz von Funktionen auf, um den Status der Ressourcen und bestimmte
Informationen und Identifier der Dienste bzw. der abfragenden Funktionen
zu erhalten. Der Ressourcenmanager 1 weist auch Funktionsabfragen
auf, um vorab den Konflikt zwischen mehreren abfragenden Funktionen zu
erkennen. Dies kann beispielsweise dann der Fall sein, wenn zwei
Funktionsblöcke
zur selben Zeit auf einen Dienst zugreifen wollen. Der Ressourcenmanager 1 stellt
dann für
diese Funktionsblöcke 4 bestimmte
Regeln auf, so dass Ressourcenkonflikte vermieden werden können.
-
Am
Ende der Start-up-Sequenz ist der Ressourcenmanager 1 über sämtliche
Funktionen 3, 4 und sämtliche Dienste des Systems informiert
und hat die notwendigen Informationen zu diesen abgespeichert. Der
Ressourcenmanager 1 wird auf Grund der nun vorhandenen
Informationen Ressourcen anfragen von den Teilnehmern 3, 4 mit
den verschiedenen Funktionsblöcken
Informationen erhalten und den Zugriff auf die im System vorhandenen
Dienste steuern.
-
In 2 ist
der Teil des erfindungsgemäßen Verfahrens
dargestellt, der während
des Normalbetriebs des Datenbussystems durchgeführt wird. Im Diagramm sind
die Verfahrensabläufe
bei der Zusammenarbeit des Ressourcenmanagers 1 mit einem
Anwendungsprogramm (Application) 8 dargestellt, welches
eine synchrone Ressource über
die Schnittstelle am Ressourcenmanager 1 anfragt. Der Funktionsblock 3a mit
der synchronen Quelle und der Funktionsblock 3b mit der
synchronen Senke für
die Dienste werden vom Ressourcenmanager 1 angesteuert.
-
Zunächst sendet
die Applikation 8 die Ressourcenanfrage 9 an den
Ressourcenmanager 1, wobei beispielsweise Sender, Empfänger, Priorität und Liste
der erforderlichen Dienste bzw. Ressourcen mitübertragen werden. Der Ressourcenmanager 1 überprüft die erforderlichen
Dienste hinsichtlich Zugreifbarkeit, basierend auf seinen internen
Datenstrukturen zu den Ressourcen. Wenn erforderlich, weist der
Ressourcenmanager 1 durch eine Kommunikation 10, 11 einen
synchronen Kanal zu und verbindet diesen mit der synchronen Quelle 3a.
In diesem Fall wirkt der Ressourcenmanager 1 als Verbindungssteuerungsgerät, welches
einem Dienst den entsprechenden Datenübertragungskanal zuweist. Gerade
bei synchroner Datenübertragung
weist dann der Ressourcenmanager 1 am speziellen Dienst
seinen synchronen Kanal innerhalb eines Datenframes auf dem Datenbus
zu.
-
Nach
der Ressourcenanfrage 9 durch eine Anwendung 8 überträgt der Ressourcenmanager 1 eine
Zuweisungsnachricht 10 an den Funktionsblock mit der synchronen
Quelle 3a für
den angefragten Dienst. Der Funktionsblock 3a bestätigt die
Anfrage und überträgt Informationen 11 über den
Dienst oder die synchrone Ressource. Der Ressourcenmanager 1 startet
daraufhin die Verbindungsprozedur 12 mit dem Funktionsblock 3b,
der als synchrone Senke für den
Dienst oder die Ressource dient. Der Funktionsblock 3b bestätigt wiederum
die Nachricht 13 und überträgt weitere
Informationen, beispielsweise eine Liste für synchrone Kanäle oder
Wartezeiten für
bestimmte Dienste. Die Bestätigungsnachricht 13 löst beim
Ressourcenmanager 1 eine Prozedur 14 aus, wobei
der Ressourcenmanager 1 an die Applikation 8 die
Anfrage bestätigt
und eine Identifier für
den Dienst als auch eine Information überträgt, ob die Anfrage erfolgreich
war, wie lange die Wartezeiten sind und/oder in welcher Form der
Dienst genutzt werden kann. Nach dem Anfrageverfahren für den Dienst nützt die
Applikation 8 während
der Nutzungsphase 15 die angefragte Ressource.
-
Am
Ende der Nutzung 15 sendet die Applikation 8 eine
Nachricht 16 an den Ressourcenmanager 1, so dass
die Verbindung zu dem Dienst oder der Ressource aufgetrennt werden
kann. Dazu wird wiederum vom Ressourcenmanager 1 an den
Funktionsblock 3b eine Nachricht 17 gesendet,
die von dem Funktionsblock 3b mit einer Nachricht 18 bestätigt wird.
Ferner sendet der Ressourcenmanager 1 eine Nachricht 19 an
den Funktionsblock 3a mit der synchronen Quelle für den Dienst
oder die Ressource, worauf der Funktionsblock 3a eine Bestätigungsnachricht 20 an
den Ressourcenmanager 1 zurücksendet und bestätigt, dass
die Dienstanfrage bzw. die Dienstnutzung beendet ist. Der Ressourcenmanager 1 übersendet
eine Bestätigungsnachricht 21 an
die Applikation 8 über
die Aufhebung der Dienstnutzung. Der Ressourcenmanager 1 vergibt
bei Anfrage nach einer Ressource eine Anfragekennung, die bei einer Applikation
bzw. Anwendungsfunktion abgespeichert wird, so dass eine zukünftige Kommunikation
im Zusammenhang mit dieser Anfrage mit den vorhergehenden Kommunikationen
in Zusammenhang gebracht werden kann. Der Ressourcenmanager 1 stellt
sicher, dass synchrone Ressourcen in keinem Fall direkt von der
Applikation 8 zugewiesen werden können.
-
In 3 ist
der Teil des erfindungsgemäßen Verfahrens
gezeigt, durch das nicht-synchrone Ressourcen über den Ressourcenmanager 1 angefragt werden.
Die Anwendung 8 stellt einen Ressourcenantrag 22 an
den Ressourcenmanager 1 und dieser wiederum kommuniziert
in einem Verfahrensschritt 23 mit einem Funktionsblock
der den Dienst oder die Ressource zur Verfügung stellen kann. Der Funktionsblock 24 bestätigt die
Anfrage durch eine Mitteilung 25 und übergibt die notwendigen Daten
an den Ressourcenmanager 1. Der Ressourcenmanager 1 benachrichtigt
durch eine Mitteilung 26 die Applikation 8 über den
Anfragezustand und etwaige Wartezeiten. Nach der Erlaubnis für einen
Dienstzugriff und die Zuordnung des Funktionsblocks 24 mit
dem Dienst durch den Ressourcenmanager 1 kann die Applikation 8 den
Dienst oder die Ressource 24 während der Nutzungszeit 27 zur
Programmausführung verwenden.
Nach Beendigung der Dienstnutzung teilt die Applikation 8 dem
Ressourcenmanager 1 über
die Anfrage 28 dies mit und der Ressourcenmanager 1 kommuniziert
in einem Verfahrensschritt 29 mit dem Funktionsblock 24,
um diesem den Abschluss der Dienstnutzung mitzuteilen. Der Funktionsblock 24 überträgt eine
Bestätigungsnachricht 30 an
den Ressourcenmanager 1 und der Ressourcenmanager 1 bestätigt den
Abschluss der Dienstnutzung durch eine Mitteilung 31 an
die Applikation 8.
-
Auch
die Funktionen des Ressourcenmanagers 1 selbst werden durch
Aufruf von einzelnen Funktionen oder Diensten des Res sourcenmanagers 1 gesteuert.
Die Funktionen können
als Softwaremodule vorgesehen sein und mittels Übergabe von Parametern aufgerufen
werden. Beispielsweise können eine
Funktion ResourceRequest, eine Funktion ResultAcknowledge und eine
Funktion RequestState vorgesehen sein.
-
In 4 ist
ein Verfahren dargestellt, bei dem der Ressourcenmanager 1 einen
Dienst eines Funktionsblocks 24 an die Applikation 8 zuweist,
wobei der Dienst zum Zeitpunkt der Zuweisung noch belegt ist. Nach
der Ressourcenanfrage 22 und der Entscheidung des Ressourcenmanagers 1,
dass die vom Funktionsblock 24 vorgesehene Ressource von der
Applikation 8 zum Zeitpunkt der Anfrage nicht aufrufbar
ist, sendet der Ressourcenmanager 1 eine Nachricht 32 an
die Applikation 8 zurück,
um die Ressourcenanfrage 22 zu bestätigen und mitzuteilen, dass
die Anfrage 22 in die Warteschlange eingereiht wurde. Sobald
dann die Ressource frei wird und der Ressourcenmanager dies aufgrund
seiner Daten oder auf Grund einer Information mitgeteilt bekommt, weist
der Ressourcenmanager 1 in dem bereits bekannten Verfahrensschritt 23 den
Funktionsblock 24 mit der Ressource zu und bestätigt in
den Verfahrensschritten 25 und 26 die mögliche Dienstnutzung an
die Applikation 8. Nach der Nutzungsdauer 27 des Dienstes
durch die Applikation 8 wird der Dienst des Funktionsblocks 24 wieder
durch die bereits beschriebenen Verfahrensschritte 28–31 freigegeben.
-
In 5 ist
der Zustand beschrieben, wenn neben der ersten Applikation 8 eine
zweite Applikation 32 den Zugriff auf die selbe Ressource
des Funktionsblocks 24 versucht. Die Sequenzdarstellung
beschreibt den Fall, wenn eine erste Applikation 8 mit geringerer
Priorität
die Ressource des Funktionsblocks 24 bereits nutzt, während eine
zweite Applikation 32 mit hoher Priorität eine Nutzung der Ressource
anfragt. Der Res sourcenmanager 1 erhält dazu von der Applikation 32 die
Anfrage 33 zur Dienstnutzung und versendet daraufhin an
die Applikation 8 mit der niederen Priorität eine Nachricht 34 zur
Abfrage des Status. Je nach Status der Dienstnutzung und den Steuerungsprozeduren
im Ressourcenmanager 1 kann dann vorgesehen sein, dass
die Applikation 8 die Nutzung der Ressource des Funktionsblocks 24 sofort
aufgibt, was den Ressourcenmanager 1 zur Nachricht 36 veranlasst,
um dem Funktionsblock 24 das Ende der Nutzung der Ressource
zu signalisieren. Das Ende der Nutzung der Ressource des Funktionsblocks 24 wird über die
Bestätigungsnachricht 37 an
den Ressourcenmanager 1 zurückgemeldet. Der Ressourcenmanager 1 bestätigt wiederum
das Ende der Dienstnutzung an die Applikation 8 mittels der
Nachricht 38. Die Nachrichten 39 und 40 sind eine
Kommunikation zwischen dem Ressourcenmanager 1 und dem
Funktionsblock 24 zur Zuweisung des Dienstes an die Applikation 32.
Die mögliche Nutzung
des Dienstes wird dann vom Ressourcenmanager 1 an die Applikation 32 mittels
der Nachricht 41 gemeldet. Nach dem Ende der Nutzungsdauer 42 wird
dann durch die Applikation 32 in dem bereits beschriebenen
Verfahren das Ende der Dienstnutzung an den Funktionsblock 24 und
den Ressourcenmanager 1 zurückgemeldet und in den Verfahrensschritten 28–31 bestätigt. Nach
Abarbeitung der hochprioren Applikation 32 meldet dann
der Ressourcenmanager 1 mittels der Nachricht 43 an
die Applikation 8, dass während einer Nutzungsdauer 44 die
Nutzung der Ressource des Funktionsblocks 24 möglich ist.
-
In
Zusammenhang mit dem eben beschriebenen Verfahren kann der Ressourcenmanager 1 verschiedene
Verfahrensweisen vorsehen, wie die Dienstbelegung mit unterschiedlichen
Prioritäten
der Applikation verknüpft
ist. Beispielsweise werden dann bei sehr hohen Prioritäten Dienstbelegungen sofort
für diese
hochpriore Applikation 32 freigegeben. Bei geringeren Priorität beider
Applikationen 8, 32 kann dann vorgesehen sein, dass
eine knappe Weiternutzungszeit des Dienstes möglich ist, jedoch dann so schnell
wie möglich
der Dienst für
die andere Applikation 32 freigegeben wird. Der Ressourcenmanager 1 kann
außerdem
eine Timerfunktion vorsehen, die einerseits eine bestimmte Weiternutzungszeit
für die
Applikation 8 mit der geringeren Priorität vorsieht
oder der Timer kann zum automatischen Beenden der Dienstnutzung
verwendet werden.
-
In 6 ist
der Teil des Verfahrens beim Herunterfahren des Systems dargestellt.
Jedes Steuergerät
besitzt eine Stromversorgungseinrichtung 45 die von einer
Stromversorgungssteuereinheit 46 an- und abgeschalten werden
kann. Die Stromversorgungssteuereinheit 46 gibt ein Abschaltesignal 47 an die
Stromversorgungseinrichtung 45 des Ressourcenmanagers 1 weiter
und diese meldet an den Ressourcenmanager 1 den Erhalt
einer Meldung zum Herunterfahren des Systems. Der Ressourcenmanager 1 startet
daraufhin einen Abschalttimer und überträgt eine Statusabfrage an jede
Anwendung, die eine Ressource oder einen Dienst zur Verfügung stellt.
Die Applikation 8 gibt mit der Meldung 50 die benutzten
Dienste, Ressourcen und den momentanen Status an den Ressourcenmanager 1 zurück. Der
Ressourcenmanager 1 überträgt eine
Nachricht 51 an den Funktionsblock 24 mit dem
von der Applikation 8 genutzten Dienst und der Funktionsblock 24 beendet
sein Dienstangebot und meldet mit der Nachricht 52 an den
Ressourcenmanager 1 zurück, dass
der Dienst nicht mehr zur Verfügung
steht. Schließlich
meldet der Ressourcenmanager 1 das Ende der Dienstnutzung
durch die Nachricht 53 an die Applikation 8 zurück. Diese
Abfrage und Bestätigungsmitteilungen
müssen
innerhalb einer Time-out-Zeit 54 erfolgen, die über den
vom Ressourcenmanager 1 überwachten Timer gemessen wird. Wenn
innerhalb der Abschaltzeit alle Ressourcen freigeschalten wurden,
beendet der Ressourcenmanager 1 die Ressourcennutzung.
Abschließend
wird die Meldung 55 an die Stromversorgungseinrichtung 45 übertra gen,
die das Ende der Ressourcennutzung bestätigt. Daraufhin gibt die Stromversorgungseinrichtung 45 des
Ressourcenmanagers 1 die Mitteilung 56 zum Abschalten
des Systems an die Stromversorgungssteuereinheit 46 weiter,
die schließlich die
gesamte Stromversorgung über
die verschiedenen Stromversorgungseinrichtungen 45 der
unterschiedlichen Steuergeräte
abschaltet. In bestimmten Fällen
kann noch vorgesehen sein, dass die Zeiterfassung 54 durch
den Ressourcenmanager 1 vor dem Abschalten verlängert wird,
wenn noch nicht alle Ressourcen für ihre Anwendungen 8 entbehrlich sind.
Es kann dann noch eine zusätzliche
Verzögerungszeit
vorgesehen sein, um hochpriore Dienste ablaufen zu lassen.