DE10040012A1

DE10040012A1 - Ressourcen-Management

Info

Publication number: DE10040012A1
Application number: DE10040012A
Authority: DE
Inventors: Vasco Vollmer; Matthias Hofmann
Original assignee: Robert Bosch GmbH
Current assignee: Robert Bosch GmbH
Priority date: 2000-08-11
Filing date: 2000-08-11
Publication date: 2002-02-21
Also published as: WO2002015483A1

Abstract

Bei einem Ressourcen-Management werden den Ressourcennutzern (200, 300) Prioritäten für die Anforderung und Belegung der Ressourcen (100) zugewiesen. DOLLAR A Häufige Bestätigungen von Belegungen durch eine Nutzer können entfallen.

Description

Stand der Technik

Die Erfindung geht aus von einem Ressourcen-Management für insbesondere an einem seriellen Bus betreibbare Ressourcen.

Aus dem IEEE Standard 1394 [1] ist ein serielles Bussystem bekannt, bei dem verschiedene Endgeräte (Knoten) entweder über ein 4-6 adriges Kabel oder einen Lichtwellenleiter angeschlossen werden. Mindestens ein Knoten kann dabei in der Art ausgeführt sein, dass er zusätzliche Verwaltungsfunktionen für das Netzwerk übernehmen kann (Busmanagement).

Neben obigem Standard gibt es eine busunabhängige Erweiterung, die unter dem Namen HAVi (Home Audio Video interoperability) [2] spezifiziert ist. Diese HAVi- Spezifikation beschreibt insbesondere die Fern-Kontrolle von Geräten unter Verwendung eines Ressourcen-Managers, der eine Ressource (Gerät) auf Anforderung belegt und sie auch wieder freigibt.

Vorteile der Erfindung

Mit dem Ressourcen-Management gemäss Anspruch 1 ist es möglich ein effektives und einfaches Ressourcen-Management durchzuführen, das eine häufige Bestätigung insbesondere von Belegungen durch einen Nutzer vermeidet. Deshalb ist dieses Ressourcen-Management insbesondere dort geeignet, wo ein Benutzer nicht durch häufige manuelle Eingaben abgelenkt werden soll, vorzugsweise in Kraftfahrzeugen. Bei der Erfindung werden den Anforderungen und Belegungen von Ressourcen Prioritäten zugewiesen. Ressourcennutzern oder Diensten mit einer hohen Priorität werden die angeforderten Ressourcen bevorzugt zugeteilt bzw. bereits belegte Ressourcen von Ressourcennutzern oder Diensten mit niedriger Priorität werden freigegeben, um sie den Ressourcennutzern oder Diensten mit höherer Priorität zuzuteilen.

Das Ressourcen-Management nach der Erfindung beeinträchtigt Funktionen innerhalb eines bestehenden Standards, z. B. dem HaVi-Standard, nicht und kann demgemäss einfach in einen solchen Standard integriert werden.

Zeichnungen

Anhand der Zeichnungen werden Ausführungsbeispiele der Erfindung näher erläutert. Es zeigen

Fig. 1 die Netztopologie eines Bussystems,

Fig. 2 die Belegung einer freien Ressource,

Fig. 3 die Übernahme einer belegten Ressource,

Fig. 4 die Abweisung einer Übernahme.

Beschreibung von Ausführungsbeispielen

Die Erfindung wird anhand des seriellen Bussystems gemäss dem IEEE Standard 1394 [1] erläutert, wobei auch auf die Erweiterung gemäss HAVi-Spezifikation [2] Bezug genommen wird. Vor der eigentlichen Erläuterung der Erfindung wird zum besseren Verständnis auf den IEEE Standard 1394 und die HAVi-Spezifikation eingegangen.

Die verschiedenen Endgeräte (Knoten) sind nach Fig. 1 entweder über ein 4-6 adriges Kabel oder einen Lichtwellenleiter 1 angeschlossen. Dabei kann ein Knoten wahlweise als Endstück (Blatt) 400 oder als Relaisknoten (Zweig) 200, 300 ausgeführt sein. Der oberste Knoten wird als Wurzel 100 bezeichnet. Durch den Einsatz der verschiedenen Knotentypen kann eine geeignete Topologie des Netzes aufgebaut werden. Ein Blatt empfängt dabei Informationspakete und verarbeitet sie, falls die Ziel- Adresse des Paketes mit der eigenen übereinstimmt. Ein Zweig muss zusätzlich alle Pakete, die er auf einem Port empfängt auf allen anderen Ports aussenden.

IEEE 1394 sieht vor, dass das Netzwerk selbstkonfigurierend ist, d. h. nach dem Einschalten oder nach einem Reset senden alle Knoten einige ausgewählte Informationen über sich selbst ins Netz. Diese Information wird dabei von allen Knoten empfangen. Ein Knoten kann dabei in der Art ausgeführt sein, dass er zusätzliche Verwaltungsfunktionen für das Netzwerk übernehmen kann (Busmanagement). Dazu sammelt er alle Informationen der andere Knoten, verarbeitet sie und speichert sie intern geeignet ab. Sollten mehrere Knoten Busmanagementfähigkeiten besitzen, gibt es ein Konkurrenzverfahren, aus dem ein Knoten als Sieger hervorgeht, der dann das Busmanagement übernimmt.

Neben den Verfahren, wie sie in den Spezifikationen zu IEEE 1394 beschrieben sind, gibt es die busunabhängige Erweiterung HAVi, die für den Einsatz in einem IEEE 1394- Netzwerk geeignet ist. Insbesondere die Fern-Kontrolle von Geräten von jedem anderen Punkt im Netzwerk wird in der HAVi-Spezifikation beschrieben. Dazu ist ein verteiltes Modell beschrieben, bei dem die Steuerung der Geräte über Kontrollmodule, sogenannte "Device Control Modules (DCM)", vorgenommen wird. Diese DCM laufen als Softwareelement auf dem Gerät, das Kontrollfunktionen auf einem anderen Gerät ausführen will. Dabei ist ein DCM jeweils spezifisch für ein bestimmtes Gerät oder eine Geräteklasse. Eine weitere Gruppe von Softwareelementen stellen die "Functional Component Modules" dar, von denen jeweils mehrere hierarchisch unterhalb eines DCM angeordnet werden können und die für die Kontrolle jeweils eines spezifischen funktionalen Teils eines Gerätes zuständig, sind.

Eine wesentliche Anforderung an ein solches System ist die durchgängige Behandlung von kollidierenden Gerätezugriffen, d. h. die Behandlung von zwei oder mehr gleichzeitigen Belegungsanforderungen auf ein Gerät. Dabei kann zwischen solchen Geräten unterschieden werden, die mehr als einen Zugriff erlauben, z. B. DAB-Tuner und solchen, die jeweils nur einen Zugriff gestatten, z. B. Lautsprecher. Der HAVi- Standard sieht einen oder mehrere Ressourcen-Manager 400 vor, die eine Ressource (Gerät) 100, 200, 300 auf Anforderung belegen und sie auch wieder freigeben. Im Sprachgebrauch von HAVi gibt es sogenannte Contender, damit werden Softwareelemente bezeichnet, die einen Zugriff auf eine oder mehrere Ressourcen anfordern. Außerdem gibt es Clients, entsprechend sind dies Softwareelemente, die derzeit eine Ressource mit einem Zugriff belegt haben - nach einer erfolgreichen Anforderung wird also ein Contender zu einem Client.

Dabei unterscheidet HAVi zwischen sogenannten User- Clients/Contendern, d. h. Softwareelementen, die i. a. bei Bedarf bei einem Anwender eine Bestätigung einholen können und System-Clients/Contendern, die keine Interaktion vom Benutzer fordern. Dementsprechend haben User- Client/Contender weitergehende Rechte, so kann ein User- Contender jederzeit eine bereits belegte Ressource übernehmen, da i. a. der Benutzer die entsprechende Entscheidung getroffen hat. Ein Beispiel dafür ist die Aufzeichnung einer Fernsehsendung auf einem Videorecorder. Wenn bereits für die gleiche Zeit eine andere Sendung zur Aufzeichnung programmiert war, kann der Benutzer entscheiden, welche der Programmierungen er behalten möchte.

Für die Nutzung im Kraftfahrzeug ist die Unterscheidung in nur zwei Stufen (User/System) häufig nicht ausreichend und die häufige Bestätigung durch den Benutzer (Fahrer) nicht sinnvoll. Die vorliegende Erfindung beschreibt ein Ressourcen-Management, das sich als Erweiterung zum HAVi- Standard mit zusätzlichen Stufen einfügen lässt.

Durch das erfindungsgemäße Verfahren wird dem HAVi-Standard eine zusätzliche Möglichkeit hinzugefügt, Anforderungen und Belegungen von Ressourcen Prioritäten zuzuweisen. Diese Erweiterung beeinträchtigt die Funktion eines Standard-HAVi- Gerätes nicht, ermöglicht aber Ressourcen (Geräte), die das erfindungsgemäße Verfahren verwenden, ein effizientes und einfaches Ressourcen-Management.

Die Erfindung gewährleistet eine Unterscheidung der Wichtigkeit einer bestimmten Ressourcenanforderung im Vergleich zu der aktuell gültigen Ressourcenbelegung. Bei einer niederprioreren bestehenden Belegung soll das belegende Softwareelement die Ressource freigeben, so dass diese dann vom höherpriorisierten Softwareelement benutzt werden kann. Der bestehende HAVi-Standard beschreibt eine Programmierschnittstelle (Application Programming Interface, API), mit Hilfe derer ein Zugriff auf die Netzwerk- und Systemfunktionen realisiert wird. Für den Ressourcen-Manager sind dabei einige Funktionsaufrufe und zu übergebende Parameter definiert. Diese dienen einem Softwareelement dazu, eine Ressource zu belegen und wieder freizugeben. Im einzelnen sind für das erfindungsgemäße Verfahren relevant (vgl. [2], Kap. 5.7.1, Kap. 5.10.1):

- FCM::Reserve
- ResourceManager::Reserve
- ResourceManager::Negotiate
- <Client<::PreemptionRequest.

Der Aufbau der Funktionsaufrufe im HAVi beruht auf der Interface Description Language (IDL). Dabei ist das Format allgemein: ZIEL::KOMMANDO. ZIEL bezeichnet dabei das Softwareelement, das KOMMANDDO ausführen soll. Das ZIEL gibt dabei häufig einen Rückgabewert über den Erfolg oder Misserfolg von KOMMANDO aus (Status). Außerdem können Parameter als "in" oder "out" definiert werden, je nachdem, ob sie mit dem Funktionsaufruf übergeben werden (in) oder nach dem Funktionsaufruf von ZIEL übergeben werden (out).

Damit sehen die HAVi-Funktionsaufrufe, an denen beim erfindungsgemäßen Verfahren Änderungen vorgenommen werden, wie folgt aus:
Resource-Manager:: Reserve(
in boolean preemptive,
in ClientRole role,
in wstring<50< info,
in sequence<ResourceRequestRecord< requestRecords,
out sequence<ResourceStatusRecord< status Records)
Status ResourceManager::Negotiate(
in boolean request,
in ClientRole role,
in long negotiateTimeout,
in wstring<50< info,
in sequence<SEID< resources,
out sequence<ResourceNegotiateRecord< negotiateRecords)
Status<Client<::PreemptionReguest(
in boolean request,
in sequence<SElD< resources,
in SEID contender,
in long preemptionTimeout,
in ClientRole role,
in wstring<50< inInfo,
out wstring<50< outInfo)
Status Fcm::Reserve(
in SEID client,
in ClientRole role,
in wstring<50< info,
in boolean primary,
in boolean nonIntrusive,
in OperationCode preemptionRequestCode)

Dabei ist für die vorliegende Erfindung jeweils der Info (auch: inInfo, outInfo) Parameter relevant. Dieser Parameter dient gemäß dem HAVi-Standard dazu dem Anforderer (Contender) bzw. Client zusätzliche Informationen über den aktuellen Vorgang zukommen zu lassen.

Das erfindungsgemäße Verfahren verwendet einen Eintrag in diesen Info-Feldern, um den Client über die Priorität zu informieren, mit der der Contender die Ressource anfordert. Wenn ein Client eine Anforderung für eine Ressource erhält, die eine höherwertige Priorität enthält als seine eigene, soll dieser Client die Ressource freigeben.

Besonders vorteilhaft ist es den Eintrag der zugeordneten Priorität mit einem eindeutigen Token zu kennzeichnen, so dass Geräte, die das erfindungsgemäße Verfahren beinhalten, unterscheiden können, ob es sich um den Eintrag der Priorität gemäß des erfindungsgemäßen Verfahrens handelt oder einen andersartigen Eintrag. In der Folge wird hier als Eintrag das Format CIAN_PRIO : X; angenommen, wobei X als Platzhalter für den Wert der Priorität steht. Es ist aber auch eine andere ASCII-Zeichenfolge denkbar. Auch ist es denkbar mehr als ein Zeichen zur Kodierung der Priorität zu verwenden. Das Semikolon in der Zeichenfolge dient als Trennzeichen zu einem evtl. folgenden Eintrag. Zusätzlich ist es möglich, ein anderes oder kein Trennzeichen zu definieren.

In dem in Fig. 1 dargestellten Netzwerk sind mit den Bezugszeichen 100, 200 und 300 Netzelemente (Geräte) bezeichnet. Das Netzelement 400 bezeichnet ein Gerät, das zusätzlich oder ausschließlich als Ressourcen-Manager operieren kann.

Die Ressource 100 erlaubt nur einen einfachen Zugriff, beispielsweise ein digital ansteuerbarer Lautsprecher. Das Gerät 200 kann auf die Ressource 100 zugreifen, z. B. ein Radio.

Das zweite Gerät 300 kann ebenfalls auf die Ressource 100 zugreifen, z. B. ein Navigationsgerät. In Fig. 2 ist die Belegung einer freien Ressource (Lautsprecher 100) durch das Radio 200 dargestellt.

Während der Fahrt schaltet der Fahrer das Radio 200 ein. Dieses reserviert unter Verwendung des Ressourcen-Managers 400 die benötigte Ressource 100. Der Contender (Radio 200) sendet eine Reservierungsanfrage 111 an den Ressourcen- Manager 400. Der Ressourcen-Manager 400 sendet eine Anfrage 112 an das Radio 200, welches eine Positivmeldung 113 zurücksendet. Da sonst keine weitere Belegung der Ressource 100 existiert, erteilt der Ressourcen-Manager 400 dem Radio 200 den Zugriff 114 auf die Ressource 100. Das Radio spielt jetzt Audiodaten auf dem Lautsprecher ab. Das Radio 200 erhält vom Ressourcen-Manager 400 eine positive Bestätigung 115. Nach einiger Zeit schaltet der Fahrer sein Navigationsgerät 300 ein und gibt ein Ziel ein. Zur Zielführung verwendet das Navigationsgerät Sprachausgaben, die über die gleiche Ressource 100 ausgegeben werden. Beide Geräte 200 und 300 beinhalten eine Vorrichtung nach dem erfindungsgemäßen Verfahren. Die Hersteller der beiden Geräte haben jeweils eine angemessene Priorität angegeben. Vorteilhaft ist dabei die Verwendung von 10 Prioritätsstufen (0 . . . 9). Dabei sollte die höchste Stufe für Systemfunktionen und Systemwartung reserviert sein. In diesem Beispiel dient dazu die Priorität 0, d. h. 0 entspricht der höchstwertigen, 9 der niederwertigsten Priorität. Das Radio 200 hat in diesem Beispiel eine Priorität von 6, das Navigationsgerät eine Priorität von 4.

Wenn das Navigationsgerät 300 eine Sprachausgabe machen will (Fig. 3) fordert es beim Ressourcen-Manager 400 die Ressource Lautsprecher 100 mit dem Funktionsaufruf ResourceManager::Reserve (211) an (Fig. 2). Mit diesem Aufruf übergibt das Navigationsgerät Parameter, die relevante Informationen über diese Reservierungsanforderung enthält. Zusätzlich zu den im HAVi-Standard definierten Inhalten enthält der Parameter "info" die Zeichenfolge "CIAN_PRIO : 4;". Der Ressourcen-Manager 400 erfragt daraufhin von der Ressource 100 den aktuellen Belegungsstatus 212. Da die Ressource derzeit vom Radio 200 belegt ist, gibt der Ressourcen-Manager 400 dem Navigationsgerät 300 eine Rückmeldung 213, dass die Reservierung fehlgeschlagen ist. Daraufhin sollte das Navigationssystem 300 bei der Ressource 100 den aktuellen Reservierungszustand 214 erfragen, um zu erfahren, warum die Reservierung der Ressource fehlgeschlagen ist. Durch die bei dieser Abfrage übertragenen Informationen kann das Navigationsgerät 300 erkennen (215), dass die derzeitige Belegung der Ressource durch das Radio 200 geschieht und eine niedrigere Priorität hat, als die, die dem Navigationsgerät zugeordnet ist.

Daraufhin wird das NavigationsgeräL den Ressourcen-Manager 400 anweisen, über die Übernahme der Ressource zu verhandeln. Der dazu verwendete Funktionsaufruf ResourceManager::Negotiate 216 beinhaltet dabei neben der Priorität des Navigationsgerätes 300 den Eintrag, dass diese Verhandlung "Preemptive" sein soll, d. h. zu einer Übernahme der Ressource führen soll. Der Ressourcen-Manager 400 sendet daraufhin eine Übernahmeanfrage an das Radio 200. Die dazu verwendete Funktion <Client<::PreemptionRequest 217 beinhaltet wiederum unter anderem die Priorität des anfragenden Gerätes (hier: Navigationsgerät). Das belegende Gerät (hier: Radio 200) prüft jetzt, ob die Priorität des anfragenden Gerätes höher ist (218), als die eigene und antwortet mit einer Zustimmung 219 zur Übernahme der Ressource, wenn die fremde Priorität höherwertiger ist als die eigene. Andernfalls kann sie dennoch zustimmen, wird im allgemeinen jedoch eine Übernahme ablehnen.

Nach einer Zustimmung durch das Radio 200 sendet der Ressourcen-Manager 400 eine Erfolgsmeldung 220 an das anfragende Navigationsgerät 300. Dieses kann daraufhin mit einem erneuten Aufruf der Funktion "ResourceManager::Reserve" 221 den Ressourcen-Manager anweisen die Ressource zu allokieren und dem Navigationsgerät 300 zuzuweisen. Dies geschieht durch Übergeben des Parameters "Preemptive". Aufgrund dieses Funktionsaufrufes wird der Ressourcen-Manager 400 die angeforderte Ressource 200 reservieren (222) und bei erfolgter Reservierung 223 dies dem Navigationsgerät 300 mitteilen (224).

Fig. 4 zeigt die entsprechende Abfolge für den Fall einer Abweisung, d. h. hier ergibt die Überprüfung der Priorität 218, dass das Gerät 300 eine niedrigere Priorität hat als das Gerät 200.

Die Prioritäten für einzelne Geräte oder Dienste müssen nicht in einem Standard festgeschrieben werden, sondern können vom Hersteller des Gerätes oder Dienstes vergeben werden.

Da alle benötigten Informationen bereits nach der ersten Abfrage des Zustands der Ressource (FCM::GetReservationStatus) im Ressourcen-Manager bekannt sind, insbesondere die Priorität des belegenden und des anfragenden Gerätes, kann auch statt einer Abweisung direkt der Befehl <Client<::PreemptionReguest zur Übernahme der Ressource für den Contender gesendet werden, sofern der Contender eine höhere Priorität hat. Damit kann der Vorgang erheblich gekürzt werden.

Literatur

[1] IEEE, "P1394a Draft for a High Performance Serial Bus (Supplement)"
[2] HAVi Organization, "The HAVi Specification 1.0"

Claims

1. Ressourcen-Management für insbesondere an einem seriellen Bus betreibbaren Ressourcen mit folgenden Merkmalen:

- den Anforderungen und Belegungen von Ressourcen (100) sind Prioritäten zugewiesen,
- Ressourcennutzern oder Diensten (300) mit einer hohen Priorität werden die angeforderten Ressourcen (100) bevorzugt zugeteilt bzw. bereits belegte Ressourcen von Ressourcennutzern (200) oder Diensten mit niedriger Priorität werden freigegeben, um sie den Ressourcennutzern oder Diensten mit höherer Priorität (300) zuzuteilen.

2. Ressourcen-Management nach Anspruch 1, dadurch gekennzeichnet, dass ein Ressourcen-Manager (400) vorgesehen ist, sowie den Ressourcennutzern (200, 300) zugeordnete Softwareelemente, die in Interaktion mit dem Ressourcen-Manager (400) die Belegung von Ressourcen (100) steuern.

3. Ressourcen-Management nach einem der Ansprüche 1 oder 2, dadurch gekennzeichnet, dass für den Ressourcen-Manager (400) Funktionsaufrufe und zu übergebende Parameter an die Softwareelemente definiert sind.

4. Ressourcen-Management nach einem der Ansprüche 2 oder 3, dadurch gekennzeichnet, dass ausgewählte Softwareelemente eingerichtet sind, Rückgabewerte über den Erfolg oder Misserfolg von Belegungsanforderungen abzugeben.

5. Ressourcen-Management nach Anspruch 3 oder 4, dadurch gekennzeichnet, dass die Prioritäten innnerhalb der Funktionsaufrufe in Info-Feldern eindeutig gekennzeichnet werden, um sie von anderen Einträgen in den Info-Feldern zu unterscheiden.

6. Ressourcen-Management nach einem der Ansprüche 2 bis 5, dadurch gekennzeichnet, dass ein Ressourcennutzer (200, 300) eingerichtet ist, nach einem Misserfolg einer Belegungsanforderung direkt mit der Ressource (100) zu kommunizieren, um den Reservierungszustand der Ressource zu erfragen, um daraufhin mit dem Ressourcen-Manager (400) über die Übernahme der Ressource zu verhandeln.

7. Ressourcen-Management nach einem der Ansprüche 1 bis 6, dadurch gekennzeichnet, dass die Vergabe von Prioritäten geräte- und/oder diensteabhängig vorgenommen wird, wobei diese Vergabe entweder fest vereinbart ist oder vom Geräte- und/oder Diensteanbieter erfolgt.

8. Ressourcen-Management nach einem der Ansprüche 1 bis 7, dadurch gekennzeichnet, dass das Ressourcen-Management in ein selbstkonfigurierendes Busnetz eingebunden ist.