Es ist Aufgabe der vorliegenden Erfindung ein
Verfahren zur Steuerung der Dienstbelegung in einem Datenbussystem
vorzuse hen, 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 Resourcenanfrage übermittelt
werden. Eine Applikation kann alternativ auch ihre Resourcenanfrage
mit einem Applikations-Identifier an den Ressourcenmanager senden,
der Resourcenmanager sendet eine Anfrage an den Prioritätenmanager,
der den aktuellen Gesamtsystemzustand kennt und aufgrund dessen
der Resourcenanfrage mittels des Applikations-Identifiers eine Priorität zugeordnet
wird. Der Prioritätsmanager
teilt dann die Priorität
dem Resourcenmanager 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 Freigabeverfah rens 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 Datenbus jeder resourcenanbietende 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 ein heitliche 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 Datenbus
und damit verknüpfte Dienst
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 Verfahren gemäß Anspruch
1, d.h. die Verwaltung der Datenbus-bezogenen 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
bestimm ten 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 sollte für synchrone
Ressourcen des Datenbus existierende Schnittstellenfunktionen verwendet
werden. Für
alle anderen Ressourcen können
Funktionen wie ein Ressourcenzähler,
Ressourceninfo, Ressourcenkonflikt, Ressourcen festlegen, Ressourcen
ent fernen, und Ressourcenverwendung vorgesehen sein. Der Ressourcenmanager
besitzt einen Fehlerbehandlungsalgorithmus, über den auch Funktionen bzw.
Dienstanfragen bearbeitet werden können, die 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 Ressourcenanfrage 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. Dieses Verhalten hat nichts mit Datensicherheit
zu tun, sondern erhöht
die Offenheit und Flexibilität
des Systems. 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 Ressour cenmanager 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 Kommunikation 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 über prü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 Ressourcenmanagers 1 gesteuert.
Die Funktionen können
als Softwaremodule vorgesehen sein und mittels Übergabe von Parametern aufgerufen
werden. Beispielsweise kann 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 Appli kation 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 Ressourcenmanager 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.
Im 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 Funkti onsblock 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 übertragen,
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.