-
GEBIET DER ERFINDUNG
-
Die
Erfindung betrifft ein Computerprogrammprodukt, das computerausführbare Anweisungen
umfasst, die, wenn sie auf einem Computer ausgeführt werden, den folgenden Schritt
durchführen:
- Registrieren einer Eigenschaftsverbindung,
die eine erste Eigenschaft von einem ersten Softwareobjekt mit einer
zweiten Eigenschaft von einem zweiten Softwareobjekt verbindet,
derart, dass eine Änderung
in der ersten Eigenschaft beim Aufrufen der Eigenschaftsverbindung
das Ausgeben eines Anrufs an das zweite Softwareobjekt verursacht,
wobei die entsprechenden Eigenschaften durch Anrufe an die entsprechenden Objekte
verändert
werden können.
-
Die
Erfindung betrifft auch ein Verfahren zum Ermöglichen des Steuerns eines
Informationsverarbeitungssystems und das den folgenden Schritt umfasst:
- Registrieren einer Eigenschaftsverbindung,
die eine erste Eigenschaft von einem ersten Softwareobjekt mit einer
zweiten Eigenschaft von einem zweiten Softwareobjekt verbindet,
derart, dass eine Änderung
in der ersten Eigenschaft beim Aufrufen der Eigenschaftsverbindung
das Ausgeben eines Anrufs an das zweite Softwareobjekt verursacht,
wobei die entsprechenden Eigenschaften durch Anrufe an die entsprechenden Objekte
verändert
werden können.
-
Die
Erfindung betrifft auch noch ein Informationsverarbeitungssystem,
das eine erste physische Komponente und eine zweite physische Komponente und
einen Computer zum Ausführen
der computerausführbaren
Anweisungen des Computerprogrammprodukts umfasst.
-
Dies
wird insbesondere, aber nicht ausschließlich, zum Steuern von Unterhaltungselektronikausrüstung in
der Heim- oder Büroumgebung
vorgenommen.
-
STAND DER TECHNIK
-
Es
wird ein Client-Server-Modell in Betracht gezogen, das auf einer
Komponentenobjektmodell-Technologie (Component Object Model – COM) von
Microsoft basiert. Weitere Informationen siehe z.B. „the Component
Object Model Specification version 0.9" vom Oktober 1995, wie durch Microsoft
geliefert. COM ist objektorientiert. Ein Objekt hat Eigenschaften,
die Steuerfunktionen von einem zugeordneten elektronischen Gerät, wie es
einer Softwareanwendung ausgesetzt ist, darstellen. Eine Zustandsänderung
eines Objekts als eine Auswirkung von einem Ereignis von außerhalb
wird an die Softwareanwendung weitergegeben. Die Anwendung manipuliert
die Objekte durch Ändern
oder Einstellen ihrer Eigenschaften. Wenn die Anwendung eine Eigenschaft
von einem Objekt, das einem bestimmten physischen Gerät zugeordnet
ist, ändert,
wird ein Befehl an das verbundene Gerät gesendet.
-
COM
ist ein generischer Mechanismus, der es Anwendungen ermöglicht,
auf konsistente Art und Weise zu kommunizieren, und ist ein Rahmen
zum Entwickeln und Unterstützen
von Programmkomponentenobjekten. Es stellt Fähigkeiten bereit, die denjenigen ähnlich sind,
die in CORBA (Common Object Request Broker Architecture), dem Rahmen
für das Zusammenwirken
von verteilten Objekten in einem Netz, definiert sind. OLE (Object
Linking and Embedding) stellt Dienste für das zusammengesetzte Dokument,
das die Benutzer auf ihrer Anzeige sehen, bereit, COM stellt die
zugrunde liegenden Dienste der Schnittstellenaushandlung und Event
Services (die ein Objekt als Ergebnis eines Ereignisses, das in
einem anderen Objekt eingetreten ist, in Betrieb setzen) bereit.
In dieser Ausführung
sind die Clients als OLE-Automatisierungsobjekte (abstrakte Darstellungen)
modelliert, die Eigenschaften verwenden, um Steuerungen und Ereignisse
Signalzustandsänderungen
auszusetzen. OLE-Automatisierung ist eine COM-Technologie, die das
Scripting und späte
Anbinden von Clients an Server ermöglicht. OLE-Automatisierung
stellt durch Anrufe an Merkmale (Befehle und Abtragen), die die
Programme zur externen Verwendung verfügbar gemacht haben, Kommunikation mit
anderen Programmen bereit. Vor der Verwendung eines Objekts muss
die Client-Anwendung zuerst den Schnittstellenzeiger des Objekts
erhalten. Der Schnittstellenzeiger wird durch das Netzverzeichnis
durch Binden des Objektnamens oder durch Aufzählen von Vorrichtungen erhalten.
Standard COM-APIs für
Monikerbindung können
verwendet werden. Verweise auf Objekte können durch Anrufen von GetObject
oder CoGetObject mit einer Zeichenfolge, die den Namen oder die
ID der gewünschten Vorrichtung
spezifiziert, erhalten werden. Die Anwendung kann dann das Objekt
durch Einstellen oder Wiederauffinden seiner Eigenschaften durch „Eigenschaft
einstellen" Anrufe
an die geeigneten Eigenschaften manipulieren. Wenn eine Anwendung
eine Eigenschaft eines Objekts, das mit einer Vorrichtung übereinstimmt,
einstellt oder verändert,
wird der Arbeitsablauf des Einstellens oder Veränderns der Eigenschaften in
einen Befehl umgewandelt, der über das
Netz an die entsprechende Vorrichtung gesendet wird. Die Objekte
können
sich in ihrer Ausführung
unterscheiden aber sie weisen für
Client-Anwendungen, die auf einem Kontroller, z.B. einem PC mit
einem Windows-basierten Betriebssystem, laufen, ein gleichartiges
eigenschaftsbasiertes Modell auf.
-
Ein
Steuerungssystem eines Peripheriegeräts des bisherigen Standes der
Technik, das mehrere Objekte und ein Programmierverfahren dafür verwendet,
sind aus
EP 0 762 273
A1 bekannt, die ein Schnittstellenobjekt bereitstellt,
das eine Funktion für das
Kommunizieren von Eigenschaften zwischen einem ersten Steuerungsobjekt
und einem zweiten Steuerungsobjekt und eine Funktion zum Kommunizieren
von Ereignissen vom zweiten Steuerungsobjekt zum ersten Steuerungsobjekt
hat.
-
AUFGABE DER
ERFINDUNG
-
Es
wird ein Informationsverarbeitungssystem in Betracht gezogen, das
solche Objekte (d.h. eine Sammlung von Softwaremodulen, wie vorhergehend
eingeführt)
und Client-Softwareanwendungen umfasst, die die Interaktion zwischen
den Objekten steuern. Das System umfasst zum Beispiel ein Heimautomatisierungs-Teilsystem
mit Audio-/Videoausrüstung
zur Unterhaltung, ein Sicherheits-Teilsystem und ein Hausklimatisierungssteuerungs-Teilsystem. Diese
Teilsysteme und ihre Komponenten sind als OLE-Automatisierungsobjekte modelliert,
die Eigenschaften verwenden, um ihre Steuerungen Anwendungs-Clients
und Ereignissen auszusetzen, um den Anwendungs-Clients Zustandsänderungen
zu signalisieren. Die Teilsysteme können unterschiedliche Kommunikationsprotokolle
für ihre
Steuersignale verwenden. Dementsprechend kommunizieren sie, da sie
nicht direkt miteinander kommunizieren können, auf Objektebene. Eine
Client-Anwendung könnte sich
für die
Benachrichtigung über Änderungen
der „Zustands"-Eigenschaft eines
ersten Objekts, das ein erstes (Software)-Teilsystem oder eine erste
Vorrichtung darstellt, registrieren und durch Einstellen einer spezifischen
Eigenschaft eines zweiten Objekts, das ein zweites Teilsystem oder
eine zweite Vorrichtung darstellt, reagieren. Die Client-Anwendung müsste indes
ständig
in Betrieb sein, um diese Interaktion bereitzustellen. Eine alternative
Lösung
ist daher, anzugeben, dass der neue Wert der Eigenschaft, immer, wenn
eine Änderung
einer Eigenschaft eines ersten Objekts eintritt, als ein SetProperty
Anruf an eine Eigenschaft eines zweiten Objekts verbreitet wird.
Dieser Mechanismus wird als eine Eigenschaftsverbindung bezeichnet.
Eine Eigenschaftsverbindung stellt eine Verbindung zwischen Objekten
her und ist im Netzverzeichnis selbst als ein systemweites OLE- Automatisierungsobjekt
registriert. Das Registrieren einer Verbindung erzeugt typischerweise
eine Verbindung zwischen Eigenschaften aber nicht notwendigerweise
zwischen Eigenschaften von unterschiedlichen Objekten. Immer, wenn
sich eine erste Eigenschaft ändert,
löst die Änderung
einen Anruf über
die registrierte Verbindung, die die Verbindung zwischen diesen
Eigenschaften bildet, zum Ändern
einer zweiten Eigenschaft aus.
-
Dieser
Mechanismus birgt indes einige Nachteile. Zum Beispiel kann die
Zustandsänderung der
Eigenschaft eines Objekts durch einen Einfluss außer einer
bestimmten Client-Anwendung, die die Verbindung, die die Eigenschaft
dieses Objekts umfasst, registriert hat, ausgelöst werden. Unter diesen Umständen sollte
die Zustandsänderung
nicht das Aufrufen dieser bestimmten Verbindung verursachen. Das
Problem entsteht zum Beispiel, wenn mehrere Verbindungen eine oder
mehrere Eigenschaften gemein haben. Dieses Teilen von einer oder mehreren
Eigenschaften durch die Verbindungen ist insbesondere in einer offenen
Architektur wie einem Heimnetz wahrscheinlich, wo Geräte nach
Belieben hinzugefügt
oder ersetzt werden. Zum Veranschaulichen des Problems wird zum
Beispiel eine erste Client-Anwendung, die eine erste Eigenschaftsverbindung
registriert, und eine zweite Anwendung, die eine zweite Eigenschaftsverbindung
registrier, in Betracht gezogen. Wenn eine Eigenschaft (1) eines
Objekts A von einem Zustand „0" zu einem Zustand „1" geändert wird,
wird die erste Verbindung aufgerufen, was verursacht, dass eine
Eigenschaft (2) von einem Objekt B ihren Zustand von „0" auf „1" ändert. Die zweite Verbindung
gibt indes an, dass eine Änderung der
Eigenschaft (1) von Objekt A vom Zustand „0" zum Zustand „1" zu einer Änderung der Eigenschaft (3)
eines Objekts C vom Zustand „0" zum Zustand „1" ergibt. Wenn sowohl
die erste Verbindung als auch die zweite Verbindung registriert
wurden, verursacht das Aufrufen der ersten Verbindung beim System
die Annahme eines Zustands, der weder dem erwünschten Endzustand für die erste
Anwendung noch dem erwünschten
Endzustand für
die zweite Anwendung entspricht, da sowohl das Objekt B als auch
das Objekt C durch Ändern
der Zustände
ihrer Eigenschaften reagieren. Ferner können Nebenerscheinungen, wenn
mehrere Anwendungen zugeordnete Eigenschaftsverbindungen registrieren
und entregistrieren, einen vollständigen Zusammenbruch des Systems verursachen.
Zum Beispiel registriert eine bestimmte Anwendung eine spezifische
Verbindung, um das System mit einem im Voraus angegebenen Verhalten zu
versehen. Wenn eine andere Anwendung eine Verbindung hinzufügt, die
eine Quelleigenschaft mit der ersten Verbindung gemein hat, aber
eine unterschiedliche Zieleigenschaft hat, oder die erste Verbindung
vollständig
entfernt, können
sich daraus Konflikte ergeben, die das System funktionsunfähig oder
sogar selbstzerstörerisch
machen.
-
Es
ist daher eine Aufgabe der Erfindung, zu gewährleisten, dass unter Verwendung
des Eigenschaftsverbindungsmechanismus ein Zustand angenommen wird,
der durch die entsprechende Anwendung erwünscht wird. Eine andere Aufgabe
ist das Vermeiden von Systemzusammenbrüchen als Ergebnis aus dem Registrieren
und Entregistrieren von Eigenschaftsverbindungen.
-
KURZDARSTELLUNG DER ERFINDUNG
-
Zu
diesem Zweck ist das Computerprogrammprodukt gemäß der Erfindung dadurch gekennzeichnet,
dass die computerausführbaren
Anweisungen, wenn sie auf dem Computer ausgeführt werden, den folgenden Schritt
durchführen:
- Zuordnen eines Anrufs an ein erstes Objekt
zu einer
-
Kennung,
die das bedingte Aufrufen der Eigenschaftsverbindung ermöglicht.
Die Kennung ist zum Beispiel eine systemweit eindeutige Nummer oder
ein Objekt. Das Objekt umfasst zum Beispiel eine Beschreibung von
allen beteiligten Verbindungen und Anwendungslogik zum bedingten
Aufrufen bestimmter Verbindungen.
-
Nun
wird die Verbindung nicht automatisch aufgerufen, nur weil die Quelleigenschaft
ihres Quellobjekts sich geändert
hat. Die Kennung verursacht das bedingte Aufrufen der Verbindung,
d.h., wenn eine oder mehrere im Voraus angegebene Bedingungen erfüllt werden.
Zum Beispiel ändert
das erste Objekt die erste Eigenschaft nach dem Empfang eines ersten
Anrufs. Nach Änderung
der ersten Eigenschaft, leitet das erste Objekt eine Nachschlagtätigkeit
ein, um zu bestimmen, ob eine Eigenschaftsverbindung der Änderung
der ersten Eigenschaft zugeordnet ist. Diese Reihenfolge der Arbeitsabläufe wird bevorzugt,
da es sein kann, dass die Eigenschaft nicht imstande ist, geändert zu
werden, oder nicht geändert
werden muss. Wenn die Reihenfolge umgekehrt wäre, würden Anrufe an das zweite Objekt
weitergeleitet, ohne, dass die Eigenschaft des ersten Objekts einer Änderung
unterzogen wird, was zu Unstimmigkeiten führt. Wenn eine oder mehrere
Eigenschaftsverbindungen gefunden werden, die der Änderung
der ersten Eigenschaft zugeordnet sind, bestimmt die Erfindung,
ob eine Übereinstimmung
zwischen der Kennung und einer oder mehreren der gefundenen Eigenschaftsverbindungen
besteht. Wenn eine Übereinstimmung
vorhanden ist, wird oder werden die Eigenschaftsverbindung oder
Verbindungen aufgerufen. Wenn keine Übereinstimmung gefunden wird,
wird die Verbindung nicht aufgerufen. Die Kennung umfasst zum Beispiel
einen Verweis auf ein Szenario zum Betrieb des Systems. Die Verbindung oder
Verbindungen, die diesem Szenario zugeordnet sind, werden mit der
Kennung im ersten Anruf angedeutet. Die Erfindung kann es ferner
einer Softwareanwendung ermöglichen,
die Eigenschaftsverbindung zu registrieren, und die Kennung im Anruf
umfasst einen Verweis auf die Softwareanwendung. Somit werden nur
Verbindungen aufgerufen, die einer spezifischen Softwareanwendung
zugeordnet sind. Die Kennung des Anrufs kann sowohl eine Szenariokennung
als auch eine Anwendungskennung haben.
-
Vorzugsweise
umfasst eine Eigenschaftsverbindung einen Verweis zur Softwareanwendung,
die die Eigenschaftsverbindung registriert hat. Beim Entfernen der
Anwendung besteht kein Bedarf mehr an den der entfernten Anwendung
zugeordneten Verbindungen. Dementsprechend werden diese Verbindungen
basierend auf ihren Verweisen auf die Anwendung entregistriert.
-
Die
vorhergehend genannte Nachschlagtätigkeit kann eine Nachschlagtabelle
oder ein dem ersten Objekt zugeordnetes Diagramm sein. Zum Beispiel
umfasst ein erstes Objekt selbst einen Nachschlagmechanismus oder
aktiviert eine Nachschlagfunktion an einer anderen Stelle im System,
wie beispielsweise einem Verbindungsmanager. Der Verbindungsmanager
ist das Softwareobjekt der Erfindung, das für das Verwalten der Eigenschaftsverbindungen verantwortlich
ist. Der Verbindungsmanager vollzieht das Registrieren und Deregistrieren
von Eigenschaftsverbindungen. Der Nachschlagmechanismus berücksichtigt
die Kennung, die angibt, ob es gegenwärtig erwünscht ist, dass die zweite
Eigenschaft des zweiten Objekts geändert wird. Die Kennung gibt zum
Beispiel ein bestimmtes Szenario von Änderungen an, die durch die
Anwendung, die eine Eigenschaftsverbindung registriert hat, beabsichtigt
werden. Wie im vorhergehend genannten Beispiel kann eine Änderung
einer Eigenschaft (1) eines Objekts A das Aufrufen von sowohl der
ersten als auch der zweiten Verbindung verursachen, wenn keine Szenariosteuerung
vorhanden ist. Wenn der Anruf das Szenario andeutet, das der ersten
Verbindung zugeordnet ist, wird die zweite Verbindung nicht aufgerufen.
-
Gemäß der Erfindung
werden mehrere Verbindungen, die ein oder mehrere Objekte teilen,
unabhängig
ausgeführt
und interferieren nicht miteinander. Die Erfindung kann eine Folge
von Eigenschaftsänderungen
aufzeichnen, derart, dass sie basierend auf den Kennungen zu einer
bestimmten Verbindung und zur Anwendung, die die Verbindung registriert hat,
zurückverfolgt
werden können.
Der letztere Fall ist zum Beispiel für Wartung und Fehlerbeseitigung von
Bedeutung. Ferner ist es, wenn eine Anwendung entfernt wird, kein
Problem, alle ihr zugeordneten Verbindungen zu entfernen. Die Verbindungen
werden wegen der Kennungen unabhängig
voneinander ausgeführt
und Verbindungen, die unterschiedlichen Anwendungen zugeordnet sind,
beeinträchtigen
einander nicht. Aufgrund dieser Unabhängigkeit kann die Erfindung
Verbindungen basierend auf z.B. dem Zustand der Erfindung, der Zeit,
den verfügbaren Ressourcen,
usw. selektiv aktivieren oder deaktivieren. Die Unabhängigkeit
der benannten Verbindungen ermöglicht
es einer Softwareanwendung oder einem Softwareagenten auch, Verbindungen
zu aktivieren oder zu deaktivieren, wenn Geräte oder Softwaremodule eingesteckt
oder ausgesteckt werden. In einem Spiel oder einer Lehrumgebung
kann eine Anwendung Verbindungen basierend auf der Anzahl, den Fähigkeiten
und dem Standort der Spieler aktivieren oder deaktivieren. Kurz
gesagt, fügt
die Unabhängigkeit
der Verbindungen, die durch ihre Bennennung mit Kennungen erreicht
wird, der Verwendung eines objektbasierten Computerprogrammprodukts einen
zusätzlichen
Grad an Freiheit hinzu.
-
Das
Verfahren gemäß der Erfindung
ist dadurch gekennzeichnet, dass das Verfahren den folgenden weiteren
Schritt umfasst:
- Zuordnen eines Anrufs an ein
erstes Objekt zu einer Kennung, die das bedingte Aufrufen der Eigenschaftsverbindung
ermöglicht.
-
Das
Informationsverarbeitungssystem gemäß der Erfindung umfasst eine
erste physische Komponente und eine zweite physische Komponente und
einen Computer zum Ausführen
der computerausführbaren
Anweisungen des Computerprogrammprodukts gemäß der Erfindung, wodurch die erste
physische Komponente durch das erste Softwareobjekt dargestellt
wird und die zweite physische Komponente durch das zweite Softwareobjekt
dargestellt wird.
-
KURZE BESCHREIBUNG
DER ZEICHNUNGEN
-
Die
Erfindung wird als Beispiel und unter Bezugnahme auf die begleitenden
Zeichnungen erklärt, wobei:
-
1 ein
Blockdiagramm ist, das szenariogesteuerte Eigenschaftsverbindungen
veranschaulicht;
-
2 ein
Blockdiagramm von einem objektorientierten System ist, das mit Objekten
konfiguriert ist, die Eigenschaften haben; und
-
3 ein
Blockdiagramm von einem anderen objektorientierten System in der
Erfindung ist.
-
BEVORZUGTE AUSFÜHRUNGSFORMEN
-
1 ist
ein Blockdiagramm 200, das das szenariogesteuerte Routing
von Eigenschaftsänderungen
gemäß der Erfindung
zwischen den Softwareobjekten 210, 212 und 214 veranschaulicht.
Das Softwareobjekt 210 hat einen Eingang 216,
einen Eingang zum Empfangen eines Eingangsanrufs, und einen Ausgang 218 zum
Ausgeben eines Ausgangsanrufs. Das Objekt 212 hat einen
Eingang 220 zum Empfangen eines Eingangsanrufs. Das Objekt 214 hat
einen Eingang 222 zum Empfangen eines Eingangsanrufs. Das
Objekt 210 hat mehrere Eigenschaften, von denen nur eine
Eigenschaft P210 gezeigt wird, um die Zeichnung nicht undeutlich
zu machen. Die Eigenschaft P210 kann durch einen Eingangsanruf am
Eingang 216, der sich auf die Eigenschaft P210 bezieht,
geändert
werden. Die Objekte 212 und 214 haben die entsprechenden
Eigenschaften P212 und P214, die durch geeignete Eingangsanrufe
an den Eingängen 220 und
beziehungsweise 222 geändert
werden können.
-
Eine
erste Client-Anwendung (nicht gezeigt) hat eine erste Verbindung
registriert, die die Eigenschaft P210 mit der Eigenschaft P212 verbindet,
derart, dass eine Änderung
bei der Eigenschaft P210 verursacht, dass das Objekt 210 am
Ausgang 218 einen Ausgangsanruf an das Objekt 212 ausgibt,
um die Eigenschaft P212 zu ändern.
Eine zweite Client-Anwendung hat eine zweite Verbindung registriert,
die die Eigenschaft P210 mit der Eigenschaft P214 verbindet, derart,
dass eine Änderung
bei der Eigenschaft P210 verursacht, dass das Objekt 210 am
Ausgang 218 einen Ausgangsanruf an das Objekt 214 ausgibt,
um die Eigenschaft P214 zu ändern. Ohne
weitere Maßnahmen
löst eine Änderung
bei der Eigenschaft P210 das Aufrufen von sowohl der ersten Verbindung
als auch von der zweiten Verbindung und somit eine Änderungen
in den beiden Eigenschaften P212 und P214 aus. Daher umfasst der Eingangsanruf
am Eingang 216 des Objekts 210 gemäß der Erfindung
eine Kennung zum selektiven Steuern des Aufrufens der geeigneten
von den ersten und zweiten Verbindungen, die die gleiche Quelleigenschaft
P210 teilen. Wenn das Objekt 210 den Anruf oder die Anfrage
am Eingang 216 empfängt, verarbeitet
es den Anruf und ändert
die Eigenschaft P210 gemäß dem Anruf.
Daraufhin löst
das Objekt 210 eine Nachschlagtätigkeit aus, um zu bestimmen, ob
eine Verbindung mit der Änderung
der Eigenschaft P210 verbunden ist. Das Objekt 210 hat
in diesem Beispiel eine Nachschlagtabelle 224, die die Verbindungen,
die mit der Änderung
der Eigenschaft P210 verbunden sind, identifiziert. Das Ergebnis
von der Nachschlagtätigkeit
ist, dass sowohl die ersten als auch die zweiten Verbindungen der
Eigenschaftsänderung
zugeordnet sind. Der Anruf am Eingang 216 umfasst eine
Kennung, um zu bestimmen, welche der der Änderung der Eigenschaft P210
zugeordneten Verbindungen aufzurufen ist. Wenn die Kennung „I" ist, schreibt die
Tabelle 224 vor, dass die erste Verbindung aufzurufen ist,
um die Eigenschaft P212 des Objekts 212 zu ändern. Wenn
die Kennung ein „II" ist, schreibt die
Tabelle 224 vor, dass die zweite Verbindung zum Ändern der
Eigenschaft P214 des Objekts 214 aufzurufen ist. Das Ändern einer
Eigenschaft vor dem Aufrufen der zugeordneten Verbindung wird aus
Gründen
der Zuverlässigkeit
vorgenommen.
-
2 ist
ein Blockdiagramm von einem Beispiel von einem Informationsverarbeitungssystem 100 gemäß der Erfindung.
Das System 100 umfasst mehrere Softwareobjekte 102, 104, 106, 108, 110 und 112.
Jedes der Objekte 102–112 stellt
ein bestimmtes steuerbares Gerät,
z.B. in einem Home-Automation-System, dar. Jedes der Objekte 102–112 hat
eine oder mehrere Eigenschaften, drei in diesem Beispiel, auf die
als Eigenschaft 1, Eigenschaft 2 und Eigenschaft 3 Bezug genommen
wird. Eine Client-Softwareanwendung 114 registriert
mehrere Verbindungen 116, 118, 120, und 122,
die Verbindungen zwischen den Objekten 102, 104, 106, 110 und 112 herstellen.
Wenn die Eigenschaft 1 des Objekts 102 ihren Zustand geändert hat,
wird die Verbindung 116 aufgerufen, um die Eigenschaft
2 des Objekts 104 zu ändern.
Wenn wiederum die Eigenschaft 2 des Objekts 104 ihren Zustand
geändert
hat, wird die Verbindung 118 aufgerufen, um die Eigenschaft
1 des Objekts 106 zu ändern.
Die Verbindung 120 wird aufgerufen, um die Eigenschaft
1 des Objekts 110 bei einer abgeschlossenen Änderung
der Eigenschaft 1 des Objekts 106 einzustellen. Das Objekt 110 ist über die Verbindung 122 mit
dem Objekt 112 verbunden, wenn die Eigenschaft 1 des Objekts 110 ihren
Zustand geändert
hat, um die Eigenschaft 2 des Objekts 112 zu ändern.
-
Ein
Beispiel des Szenarios, das durch Aufrufen der Verbindungen 116–122 ausgeführt wird,
ist das Folgende. Die Eigenschaft 1 des Objekts 102 stellt
die Ein-/Aus-Steuerungsfunktion
eines DVD-Spielers (nicht gezeigt) dar. Wenn die Eigenschaft 1 den
Zustand von „Ein" zu „Aus" ändert, ist die Tonanlage (nicht
gezeigt) zu aktivieren. Die Eigenschaft 2 des Objekts 114 stellt
die Ein-/Aus-Steuerungsfunktion der Tonanlage dar. Die Eigenschaft
2 des Objekts 104 wird durch die Verbindung 116 eingestellt.
Wenn die Tonanlage über
das Objekt 104 aktiviert wurde, sind die Lichter (nicht
gezeigt) im Raum auf einen vorbestimmten Pegel zu dämpfen. Das
Objekt 104 ruft daher die Verbindung 118 auf,
um die Eigenschaft 1 des Objekts 106 zu ändern. Das
Objekt 106 umfasst eine Softwaredarstellung des Kontrollers
(nicht gezeigt) für
eine Beleuchtungsanlage (nicht gezeigt) und die Eigenschaft 1 des
Objekts 106 stellt den Helligkeitspegel der Lichter dar, der
durch die Verbindung 118 eingestellt wird. Die Kontrollerdarstellung 106 gibt
einen Anruf an die Darstellung der Beleuchtungsanlage, hier Objekt 110,
aus, deren Eigenschaft 1 gemäß dem Zustand
des Kontrollers über
die Verbindung 120 eingestellt wird. Wenn die Lichter auf
den vorbestimmten Pegel eingestellt wurden, ruft das Objekt 110 die
Verbindung 122 auf, um den Zustand des Objekts 112,
das eine Telefonvorrichtung (nicht gezeigt) darstellt, zu ändern. Die
Verbindung 122 dient zum Deaktivieren des akustischen Signals
des Telefons, um zu verhindern, dass der Benutzer unterbrochen wird,
wenn er sich den DVD-Film ansieht. Die Eigenschaft 2 des Objekts 112 stellt
die Ein-/Aus-Steuerungsfunktion des akustischen Signals des Telefons
dar.
-
Nun
registriert eine zweite Softwareanwendung 124 die Verbindungen 126 und 128.
Die Verbindung 126 verbreitet eine Änderung des Zustands der Eigenschaft
1 des Objekts 106 zur Eigenschaft 1 des Objekts 108.
Die Verbindung 128 verbreitet eine Änderung des Zustands der Eigenschaft
1 des Objekts 106 zur Eigenschaft 1 des Objekts 110.
Im vorhergehenden Beispiel wird, wenn der Lichtkontroller, der durch
das Softwareobjekt 106 dargestellt wird, den Zustand zu „Lichter
gering" oder „Lichter
aus" geändert hat,
die Verbindung 128 zur Eigenschaft 1 des Objekts 110 aufgerufen,
das im vorhergehenden Beispiel die Beleuchtungsanlage darstellt.
Es wird auch ein Anruf an die Eigenschaft 1 des Objekts 108,
das in diesem Beispiel ein Heimsicherheitssystem (nicht gezeigt)
darstellt, ausgegeben. Das Einstellen der Eigenschaft 1 des Objekts 108 schaltet
das Heimsicherheitssystem ein.
-
Es
ist anzumerken, dass die Verbindung 128 parallel zur Verbindung 120 läuft. Wenn
die Verbindungen 128 und 120 keine unterschiedlichen
Benennungen oder Kennungen hätten,
würde eine Änderung
des Zustands der Eigenschaft 1 des Objekts 106 direkt die
Verbindungen 120, 126 und 128 und demzufolge
indirekt die Verbindung 122 aufrufen. Dies ist in diesem
Fall nicht die Absicht des Benutzers. Dementsprechend werden, durch
Benennen der Anrufe, derart, dass die Objekte imstande sind, das
zugeordnete Szenario durch die Kennungen zu identifizieren, die
Verbindung 120 einerseits und die Verbindungen 126 und 128 andererseits
sogar dann unabhängig
gemacht, wenn sie eine oder mehrere Quelleigenschaften von einem
oder mehreren Quellobjekten teilen.
-
3 veranschaulicht
ein Szenario, dass es einem Unterhaltungssystem 300 ermöglicht,
Benutzerbewegungen automatisch zu ermitteln, um einen DVD-Spieler
anzuhalten. Das System 300 umfasst ein Softwareobjekt 302,
das einen DVD-Spieler (nicht gezeigt) darstellt, ein Softwareobjekt 304,
das eine Beleuchtungsanlage (nicht gezeigt) darstellt, und ein Softwareobjekt 306,
das eine Kamera (nicht gezeigt) darstellt. Das Drücken eines
Knopfs auf einer Fernbedienungsvorrichtung 308 aktiviert
das Szenario wie folgt. Der DVD-Betriebsmodus wird auf „Play" verändert, die
Helligkeit der Lichter geht auf 20% und der Erkennungshintergrund
der Kamera wird auf „gedämpft" eingestellt und
ihr Zustand wird auf „Änderung
ermitteln" (im Stuhl
des Benutzers) eingestellt. Wenn der/die Benutzer/in aufsteht, ermittelt
die Kamera seine/ihre Bewegung durch einen Bewegungsdetektor. Beim
Ermitteln der Bewegung des Benutzers wird die „Helligkeit" auf 100% eingestellt,
der Erkennungshintergrund der Kamera wird auf „hell" eingestellt, und der DVD-Betriebsmodus
wird auf „Stop" eingestellt. Ein
gleichartiges Szenario ist möglich, wenn
der Benutzer sich ein Fernsehprogramm ansieht. In diesem Fall wird
eine automatische Aufzeichnung eines Programms aktiviert. Bei der
Rückkehr
des Benutzers wird der Inhalt ab dem Moment, an dem er verlassen
wurde, abgespielt. In einigen Fällen
könnte
ein solches Systemverhalten als unerwünscht betrachtet werden, wenn
es nicht durch ein Szenario aktiviert wurde. Zum Beispiel, wenn
der Benutzer das gegenwärtige
Programm einfach verlassen und später zurückkehren möchte, ohne sich den verpassten
Inhalt anzusehen.
-
Die
vorhergehenden Systeme 100 und 300 sind objektorientiert
und basieren auf der Steuerung von Objekteigenschaften. Ein Home
Audio/Video Interoperabilität
(HAVi-) basiertes System kann auf die gleiche Art und Weise Nutzen
aus dem Verbindungsbenennungsansatz ziehen. Als Erstes wird eine
kurze Beschreibung von HAVi gegeben, um den Kontext für eine HAVi-Ausführung eines
Systems gemäß der Erfindung
bereitzustellen.
-
Ein
Konsortium von Unterhaltungselektronikherstellern, darunter Philips
Electronics, hat Spezifikationen für einen Kern von APIs (Anwendungsprogrammierschnittstellen)
für digitale
Unterhaltungselektronikgeräte
in einem Heimnetz erarbeitet, um einen Standard für die Audio-/Videoelektronik-
und Multimediabranchen bereitzustellen. Eine API gibt das Verfahren
an, das erforderlich ist, um Anfragen an ein Betriebssystem oder
Anwendungsprogramm zu richten. Das Heimnetz wird als eine verteilte
Datenverarbeitungsplattform betrachtet. Das primäre Ziel des Standards, der
als HAVi (Home Audio/Video Interoperabilität) Architektur bezeichnet wird,
ist es, zu gewährleisten,
dass Produkte von unterschiedlichen Lieferanten miteinander arbeiten,
d.h. kooperieren können,
um Anwendungsaufgaben durchzuführen.
Gegenwärtige
Unterhaltungselektronikgeräte (DVD-Spieler,
digitale Videokameras, digitale Fernsehgeräte, usw.) sind digitale Verar beitungs-
und digitale Speicherungssysteme. Das Verbinden dieser Geräte in Netzen
ermöglicht
es, Verarbeitungs- und Speicherungsressourcen zu teilen. Dies ermöglicht das
simultane Koordinieren der Steuerung von verschiedenen Unterhaltungselektronikgeräten, z.B., um
die Interaktion mit dem Benutzer zu vereinfachen. Zum Beispiel kann
ein erstes Gerät
das Aufzeichnen auf einem zweiten Gerät instanziieren, während es auf
eine elektronische Programmzeitschrift (Electronic Program Guide – EPG) auf
einem dritten Gerät zugreift.
Das Heimnetz stellt das Gewebe für
das Verbinden der Unterhaltungselektronikgeräte bereit. Es ermöglicht es
verbundenen Geräten,
sowohl Steuerungs- (ein Gerät
sendet einen Befehl an das andere) als auch AV- (Audio/Video) Daten
(ein Gerät
sendet einen Audio- oder Video-Stream an ein anderes Gerät) auszutauschen.
Das Netz muss einigen Anforderungen genügen, um all dies zu erreichen.
Es muss den zeitnahen Transfer von AV-Streams mit hohen Datenraten
unterstützen.
Das Netz muss Selbstkonfigurierung, Selbstverwaltung und Hot-Plug-and-Play unterstützen. Es
muss Verkabelung und Schnittstellen mit niedrigen Kosten erfordern.
-
Die
HAVi-Softwarearchitektur ist plattformunabhängig und basiert auf Java.
HAVi verwendet das serielle Busprotokoll IEEE 1394 mit hoher Leistung zum
Transport von Steuerung und Inhalt unter den Geräten, die mit dem Netz verbunden
sind. Der IEEE 1394 Standard ist ein dynamisch konfigurierbares
digitales Netz mit geringen Kosten. IEEE 1394 definiert sowohl eine
physische Backplane-Schicht als auch mit Punkt-zu-Punkt-Kabeln verbundene
virtuelle Busausführungen.
Die Backplaneversion arbeitet bei 12.5, 25 oder 50 Mbits/Sek. Die
Kabelversion unterstützt
Datenraten von 100, 200 und 400 Mbits/Sek. Der Standard spezifiziert
das Medium, die Topologie und das Protokoll. Das IEEE 1394 Transportprotokoll ist
aufgrund seiner Fähigkeit
zu hohen Datenraten besonders nützlich
für das
Unterstützen
von Audio- und Videokommunikationsprotokollen.
-
Die
HAVi-Architektur steuert die Unterhaltungselektronikgeräte im Netz
durch abstrakte Darstellungen der Unterhaltungselektronikgeräte. Es wird
durch einen Kontroller auf den abstrakten Darstellungen gearbeitet
und diese verstecken die Eigenarten der zugeordneten realen Unterhaltungselektronikgeräte. Die
abstrakte Darstellung stellt somit eine einheitliche Schnittstelle
für höhere Software-Ebenen
bereit. Die abstrakten Darstellungen werden mit ihren Steuereigenschaften,
die diejenigen des dargestellten Geräts widerspiegeln, registriert. Die
abstrakten Darstellungen setzen ihre Interoperabilitäts-APIs
den Anwendungen aus und bilden gemeinsam einen Satz von Diensten
zum Aufbauen von mobilen, verteilten Anwendungen auf dem Heimnetz.
-
Die
Architektur ermöglicht
es einem Gerät, einen
Befehl oder Steuerinformationen an ein anderes Gerät im Heimnetz
zu senden. Eine HAVi-kompatible Vorrichtung umfasst Daten (vorhergehende
abstrakte Darstellung, die als Device Control Model oder DCM bezeichnet
wird, siehe weiter unten), die sich auf ihre Benutzerschnittstelle
(z.B. GUI) und auf ihre Steuerfähigkeiten
beziehen. Diese Daten umfassen zum Beispiel HAVi-Bytecode (Java), der durch andere Geräte auf dem
Netz herauf geladen und ausgeführt
werden kann. Ein HAVi-kompatibles Gerät hat als Minimum genug Funktionen,
um mit anderen Geräten
im System zu kommunizieren. Während
der Interaktion können
die Geräte
Steuerung und Daten auf Peer-to-Peer-Art austauschen. Dies gewährleistet,
dass auf der Kommunikationsebene von keinem der Geräte erforderlich
ist, als der Master oder der Kontroller des Systems zu agieren.
Andererseits ermöglicht
es einem logischen Master oder Kontroller, eine Steuerstruktur auf
dem grundlegenden Peer-to-Peer-Kommunikationsmodell vorzuschreiben.
HAVi unterscheidet wie unten weiter erklärt zwischen Kontrollern und
gesteuerten Geräten.
Ein Kontroller ist ein Gerät,
das als ein Host für
ein gesteuertes Gerät
agiert. Ein Kontroller beherbergt die abstrakte Darstellung für das gesteuerte
Gerät.
Die Steuerschnittstelle ist über
die API der abstrakten Darstellung ausgesetzt. Diese API ist der
Zugangspunkt für Anwendungen,
um das Gerät
zu steuern.
-
HAVi-kompatible
Unterhaltungselektronikgeräte
werden wie folgt kategorisiert: Full-AV-Geräte (FAVs), Intermediate-AV-Geräte (IAVs)
und Base-AV-Geräte
(BAVs).
-
Ein
FAV enthält
einen vollständigen
Satz der Softwarekomponenten der HAVi-Softwarearchitektur (siehe
unten). Ein FAV ist dadurch gekennzeichnet, dass es eine Laufzeitumgebung
für HAVi-Bytecode hat.
Dies ermöglicht
es einem FAV, Bytecode von anderen Geräten herauf zu laden, um z.B.
verbesserte Fähigkeiten
für ihre
Steuerung bereitzustellen. Ein FAV kann z.B. durch eine HAVi-kompatible Set-Top-Box,
einen HAVi-kompatiblen digitalen Fernsehempfänger und einen Heim-PC gebildet
werden. Zum Beispiel kann ein intelligenter Fernsehempfänger der
HAVi-Kontroller von anderen Geräten,
die auf dem Netz verbunden sind, sein. Der Empfänger erhält den Bytecode, der von einem
anderen Gerät
herauf geladen wurde, um eine UI für dieses Gerät zu erzeugen
und, um externe Steuerung dieses Geräts bereitzustellen. Ein Icon,
das diese Vorrichtung darstellt, kann dazu gebracht werden, auf
dem Fernsehbildschirm zu erscheinen und Benutzerinteraktion mit dem
Icon kann verursachen, dass Elemente des Steuerungsprogramms das
dargestellte Gerät
auf eine vorbestimmte Art betätigen.
-
Ein
IAV stellt keine Laufzeitumgebung für HAVi-Bytecode bereit, kann
aber native Unterstützung
für das
Steuern von spezifischen Geräten
auf dem Heimnetz bereitstellen. Ein IAV umfasst eingebettete Softwareelemente,
die eine Schnittstelle zum Steuern von allgemeinen Funktionen der
spezifischen Geräte
bereitstellen. Diese Softwareelemente müssen kein HAVi-Bytecode sein
und können
als native Anwendungen auf den IAV, die native Schnittstellen zum
Zugreifen auf andere Geräte
verwenden, ausgeführt
werden.
-
Ein
BAV kann herauf geladenen HAVi-Bytecode bereitstellen, beherbergt
aber keines der Softwareelemente der HAVi-Architektur. Ein BAV ist durch
ein FAV mittels des herauf geladenen Bytecodes des Ersteren steuerbar.
Ein BAV ist durch ein IAV über
den nativen Code steuerbar. Die Kommunikation zwischen einem FAV
oder IAV auf der einen Seite und einem BAV auf der anderen Seite
erfordert, dass der HAVi-Bytecode in und vom Befehlsprotokoll, das
durch den BAV verwendet wird, übersetzt
wird.
-
Die
Hauptsoftwareelemente, die in der Kernspezifikation der HAVi-Architektur enthalten
sind, sind die unten aufgelisteten. Für eine detailliertere Erklärung dieser
Elemente, siehe die HAVi-Spez., die hierin durch Bezugnahme aufgenommen
wird.
- 1) Ein 1394 Communications Media Manager (CMM) – agiert
als eine Schnittstelle zwischen den anderen Softwareelementen und
dem IEEE 1394.
- 2) Ein Event Manager (EM) – informiert
die verschiedenen Softwareelemente über Ereignisse im Netz, wie
beispielsweise die Änderungen
in der Netzkonfigurierung, die eintreten, wenn Vorrichtungen (Geräte) zum
Netz hinzugefügt
oder davon entfernt werden.
- 3) Ein Register – behält Informationen über die Vorrichtungen,
die mit dem Netz verbunden sind und die Funktionen, die sie bieten,
bei. Anwendungen können
diese Informationen vom Register erhalten.
- 4) Ein Messaging System (MS) – dient als eine API, die die
Kommunikation zwischen den Softwareelementen der verschiedenen Vorrichtungen auf
dem Netz erleichtert. Das Messaging System versieht die HaVi-Softwareelemente
mit Kommunikationsmöglichkeiten.
Es ist unabhängig
vom Netz und den Transportschichten. Ein Messaging System ist in
FAV und IAV eingebettet. Das Messaging System ist verantwortlich
für das
Zuweisen von Kennungen für
die abstrakten Darstellungen am FAV oder IAV. Diese Kennungen werden
zuerst durch die abstrakten Darstellungen verwendet, um sich bei
den FAV oder IAV zu registrieren. Dann werden sie durch die abstrakten
Darstellungen verwendet, um einander im Heimnetz zu identifizieren.
Wenn eine erste abstrakte Darstellung eine Nachricht an eine andere
abstrakte Darstellung senden möchte,
muss sie beim Aufrufen der Messaging-API die Kennung der Letzteren verwenden.
- 5) Ein Device Control Modul (DCM) – stellt eine Vorrichtung auf
dem Netz dar. Anwendungsprogramme können direkt mit einem DCM interagieren.
Dieses schirmt sie von den Eigenarten von jeder einzelnen Vorrichtung
ab.
- 6) Ein DCM Manager – installiert
die DCMs. Er reagiert automatisch auf Änderungen im Netz durch Installieren
neuer DCMs für
neue Vorrichtungen.
- 7) Ein Data Driven Interaction (DDI) Kontroller – gibt für ein HAVi-Softwareelement eine
GUI (Graphical User Interface – grafische
Benutzerschnittstelle) auf der Anzeige einer Vorrichtung wieder. Er
unterstützt
eine breite Palette von Anzeigen, die von grafischen bis zu „nur Text" variieren.
- 8) Ein Stream Manager (SMGR) – erzeugt Verbindungen und
routet Echtzeit-AV-Streams zwischen zwei oder mehr Vorrichtungen
im Netz.
-
Die
HaVi-Architektur spezifiziert mindestens zwei Ebenen von Interoperabilität, die als
Ebene 1 und Ebene 2 bezeichnet werden.
-
Die
Interoperabilität
der Ebene 1 wendet sich dem allgemeinen Bedürfnis zu, es bestehenden Vorrichtungen
zu ermöglichen,
auf einer Grundfunktionsebene zu kommunizieren. Um dies zu erreichen,
definiert und verwendet die Interoperabilität der Ebene 1 einen generischen
Satz von Steuernachrichten (Befehle), die es einem Gerät ermöglichen,
mit einem anderen Gerät
zu kommunizieren, und einen Satz von Ereignisnachrichten, die es
vernünftigerweise aufgrund
ihrer Klasse (Fernseher, Videorecorder, DVD-Spieler, usw.) von einer
Vorrichtung erwarten sollte. Zur Unterstützung dieses Ansatzes ist ein grundlegender
Satz von Mechanismen erforderlich: Entdeckung der Vorrichtung; Kommunikation,
und HAVi-Nachrichtensatz.
-
Was
die Entdeckung der Vorrichtung betrifft: jede Vorrichtung im Heimnetz
benötigt
ein klar definiertes Verfahren, das es ihr ermöglicht, anderen ihre Fähigkeiten
mitzuteilen. Der HAVi-Ansatz verwendet so genannte SDD-Daten (self-describing
data – selbstbeschreibende
Daten). Die SDD-Daten sind auf allen Geräten im Netz erforderlich. Die
SDD-Daten enthalten Informationen über das Gerät, auf die durch andere Geräte zugegriffen
werden kann. Die SDD-Daten enthalten, als ein Minimum, genug Informationen,
um die Instanziierung von einem so genannten eingebetteten Device
Control Modul (eingebettetes DCM) zu ermöglichen. Ein eingebettetes DCM
ist ein Stück
Code, das auf einem steuernden IAV oder FAV in plattformabhängigem Code
und unter Verwendung von nativen Schnittstellen vorinstalliert ist,
um auf die Ressourcen des IAV oder FAV zuzugreifen. Wie vorhergehend
erwähnt,
ist ein DCM für
ein Gerät
ein Softwareelement, das eine Schnittstelle für die Steuerung von allgemeinen
Funktionen des Geräts
bereitstellt. Die Instanziierung eines eingebetteten DCM ergibt
die Registrierung der Fähigkeiten
des Geräts
in einem Register. Das Register stellt einen Verzeichnisdienst bereit
und ermöglicht es
einem Objekt, auf dem Netz ein anderes Objekt auf dem Netz zu lokalisieren.
Die Registrierung ermöglicht
es Anwendungen, den grundlegenden Satz von Befehlsnachrichten, die
an ein bestimmtes Gerät auf
dem Netz gesendet werden können,
zu erkennen.
-
Was
die Kommunikation betrifft: nachdem eine Anwendung die Fähigkeiten
eines Geräts
ermittelt hat, muss die Anwendung imstande sein, auf diese Fähigkeiten
zuzugreifen. Dies erfordert eine allgemeine Kommunikationsmöglichkeit,
die es Anwendungen ermöglicht,
Anfragen an Geräte
auszugeben. Dieser Dienst wird durch die HAVi-Messaging-Systeme
und DCMs bereitgestellt. Die Anwendung sendet HAVi-Nachrichten an DCMs,
die DCMs beteiligen sich dann an der proprietären Kommunikation mit den Geräten.
-
Was
die HAVi-Nachrichtensätze
betrifft: Zur Unterstützung
von Interoperabilität
der Ebene 1 ist ein klar definierter Satz von Nachrichten erforderlich, der
durch alle Geräte
einer bestimmten bekannten Klasse (z.B., die Klasse von Fernsehempfängern, die Klasse
von Videorecordern, die Klasse von DVD-Spielern, usw.) unterstützt werden.
Dies gewährleistet,
dass ein Gerät
mit bestehenden Geräten sowie
mit zukünftigen
Geräten,
unabhängig
vom Hersteller, arbeiten kann.
-
Diese
drei grundlegenden Anforderungen unterstützen ein bestimmtes Mindestmaß an Interoperabilität. Da ein
Gerät die
Fähigkeiten
eines anderen über
das Register abfragen kann, kann ein Gerät den Nachrichtensatz, der
durch das andere Gerät
unterstützt
wird, bestimmen. Da Anwendungen Zugriff auf das Messaging-System
haben, kann ein Gerät mit
einem anderen Gerät
interagieren.
-
Die
Interoperabilität
der Ebene 1 gewährleistet,
dass Vorrichtungen auf einer Grundfunktionsebene miteinander arbeiten
können.
Es wird indes ein erweiterter Mechanismus benötigt, um es einem Gerät zu ermöglichen,
mit anderen Geräten
mit irgendeiner zusätzlichen
Funktion, die nicht in den eingebetteten DCMs auf einem FAV vorhanden
ist, zu kommunizieren. Zum Beispiel können eingebettete DCMs nicht alle
Merkmale von bestehenden Produkten unterstützen und es ist unwahrscheinlich,
dass sie die vollständig
neuen Merkmale von zukünftigen
Produktkategorien unterstützen.
Die Interoperabilität
der Stufe 2 stellt diesen Mechanismus bereit. Um dies zu erreichen,
erlaubt die HAVi-Architektur DCMs, die herauf geladen werden können, als
eine Alternative zu den vorhergehend genannten eingebetteten DCMs.
Das DCM, das herauf geladen werden kann, kann ein bestehendes DCM
auf einem FAV ersetzen. Ein DCM, das herauf geladen werden kann,
kann durch irgendeine geeignete Quelle bereitgestellt werden, aber
eine wahrscheinliche Technik ist, die DCM, die herauf geladen werden
kann, in den HAVi-SDD-Daten des BAV-Geräts anzuordnen und vom BAV in
das FAV-Gerät
herauf zu laden, wenn das BAV mit dem Heimnetz verbunden ist. Da
die HAVi-Architektur lieferantenneutral ist, ist es notwendig, dass
das herauf geladene DCM auf einer Vielzahl von FAV-Geräten mit
allen potentiell unterschiedlichen Hardwarearchitekturen funktionieren
wird. Um dies zu erreichen, werden herauf geladene DCMs in HaVi
(Java) Bytecode ausgeführt.
Die HaVi-Bytecode-Laufzeitumgebung
auf FAV-Geräten
unterstützt
die Instanziierung und Ausführung
von herauf geladenen DCMs. Nachdem es erzeugt wurde und innerhalb
eines FAV-Geräts
läuft,
kommuniziert das DCM mit den BAV-Geräten auf die gleiche Art, wie
vorhergehend beschrieben.
-
Die
Effizienz von Interoperabilität
der Ebene 2 wird klar, wenn man die Ressourcen in Betracht zieht,
die erforderlich sind, um auf eine spezifische Gerätfunktion
zuzugreifen. Ebene 2 ermöglicht
es einer Vorrichtung, über
ein herauf geladenes DCM gesteuert zu werden, das alle Fähigkeiten,
die durch das Gerät
geboten werden, aufweist, wohingegen dieses DCM, um gleichartige
Funktionen in Ebene 1 zu erreichen, irgendwo im Netz eingebettet
werden müsste.
Wenn zum Beispiel ein neues Gerät
zum Netz hinzugefügt
wird, erfordert Ebene 1, dass mindestens ein anderes Gerät ein eingebettetes
DCM umfasst, das mit dem neuen Gerät kompatibel ist. Im Vergleich
dazu erfordert Ebene 2 nur, dass ein Gerät eine Laufzeitumgebung für das herauf
geladene DCM, das vom neuen Gerät
erhalten wird, bereitstellt.
-
Das
Konzept, das darin besteht, Bytecode herauf zuladen und auszuführen, stellt
auch die Möglichkeit
von gerätespezifischen
Anwendungen, die Device Control Applications genannt werden, bereit. Durch
diese Anwendungen kann ein Gerätehersteller für einen
Benutzer eine Möglichkeit
bereitstellen, besondere Merkmale eines Geräts zu steuern, ohne dass die
Standardisierung aller Merkmale in HAVi erforderlich ist. Die Anwendung
wird durch ein DCM in HAVi-Bytecode bereitgestellt und kann durch
jedes FAV-Gerät
auf dem Netz herauf geladen und installiert werden.
-
Für weitere
Informationen wird auf die HAVi-Spezifikation und die IEEE 1394
Spezifikation, die jedermann zugänglich
sind, verwiesen. Die HAVi-Kernspezifikation wurde auf dem Netz zum
Beispiel unter http://www.sv.philips.com/news/press verfügbar gemacht.
-
Es
können
nun innerhalb des HAVi-Kontexts durch Registrierung zum Einrichten
von Nachrichtenverkehr bei Zustandsänderungen in den Geräten, die ein
HAVi-kompatibles
System bilden, Verbindungen installiert werden. Erneut werden durch
Benennen der Nachrichten unter Verwendung von Kennungen Verbindungen
von unterschiedlichen Szenarien auf die gleiche Art und Weise wie
diejenige des im unter Bezugnahme auf 1 und 2 erläuterten
objektorientierten Ansatzes unabhängig gehalten. Innerhalb dieser
unterschiedlichen Kontexte sind die Begriffe Anrufe und Nachrichten,
Objekte und HAVi-Softwaredarstellungen für den Zweck der Erfindung als
gleichbedeutend zu interpretieren.