DE60303903T2

DE60303903T2 - Verfahren zur Erzeugung einer graphischen Benutzerschnittstelle auf einem HAVi Gerät für die Steuerung eines nicht HAVi Gerätes

Info

Publication number: DE60303903T2
Application number: DE60303903T
Authority: DE
Inventors: Ingo HÜTTER
Original assignee: Thomson Licensing SAS
Priority date: 2002-04-18
Filing date: 2003-04-07
Publication date: 2006-08-24
Anticipated expiration: 2023-04-08
Also published as: KR20030082903A; EP1355485A1; MXPA03003182A; JP2003345683A; US20030200340A1; CN1452390A; CN1297133C; DE60303903D1

Description

Die Erfindung bezieht sich auf ein Verfahren zur Erzeugung einer Benutzer-Schnittstelle in einem HAVi-Gerät zur Steuerung eines Nicht-HAVi-Gerätes. Die Erfindung bezieht sich insbesondere auf das Gebiet von Heim-Kommunikations-Netzwerken. Die Erfindung betrifft auch eine Gateway-Vorrichtung zur Verwendung in dem Verfahren zur Erzeugung einer Benutzer-Schnittstelle, wie auch auf zwei Arten von Computerprogramm-Produkten.
Hintergrund
Vor einigen Jahren war der Aufbau der üblichen Heim-Audio/Video-Ausrüstung durch eine Mischung von CE-Geräten unterschiedlicher Art gekennzeichnet, z.B. einem Rundfunkempfänger, einem CD-Spieler, einem Lautsprecherpaar, einem Fernsehgerät, einem Video-Kassettenrecorder, einem Tonbandlaufwerk, einem DVD-Spieler, einem Satellitenempfänger und dergleichen. Zur Wechselwirkung der Geräte musste eine Punkt-zu-Punkt-Verbindung von analogen/digitalen Eingängen/Ausgängen hergestellt werden. Für diesen Zweck stand eine Reihe von verschiedenen Kabeln zur Verfügung, wie Scart-Kabel, Cinch-Kabel, Koaxialkabel, optische Fasern usw.
Inzwischen gibt es starke Aktivitäten auf dem Gebiet der Verbraucher-Elektronik, um diese Art von Punkt-zu-Punkt-Verbindungen zu vermeiden. Es gibt bereits eine Anzahl von Normen für Heim-Netzwerke, die verwendet werden können, um all die verschiedenen Komponenten miteinander über einen einzigen Typ eines Netzwerkkabels zu verbinden. Auf dem Gebiet der Verbraucher-Elektronik soll hier an erster Stelle die IEEE 1394-Bus-Norm genannt werden. Das IEEE 1394-Bus-System sorgt für eine Verbindung zwischen den CE-Geräten mit hoher Datenrate. Die Kabelversion stützt Datenraten von 100, 200 und 400 Mbit/s. Dies reicht, um asynchrone Daten zur Steuerung einer Netzwerkstation wie auch isochrone Audio- und Videoströme parallel zu transportieren. Isochrone und asynchrone Datentransfer-Betriebsarten werden gestützt. Die IEEE 1394-Norm spezifiziert jedoch nur die unteren Schichten des ISO/OSI-Referenz-Modells, nämlich die physikalische Schicht, die Datensicherungsschicht und die Transaktionsschicht. Daher sind die höheren Schichten, nämlich die Transportschicht, die Kommunikations-Steuerschicht (session layer), die Präsentationsschicht und die Anwendungsschicht für anwendereigene Definition offen gelassen.
Ein Konsortium von Verbraucher-Elektronik-Herstellern hat an einer Norm für die Audio/Video-Elektronik die Multimediaindustrie gearbeitet, in der die höheren Kommunikationsschichten spezifiziert worden sind. Diese Norm wird als HAVi-Norm bezeichnet, wobei HAVi für Heim-Audio/Video-Interoperabilität steht. Diese Norm hat primär eine Interoperabilitäts-Middleware definiert, die gewährleistet, dass Produkte von verschiedenen Anbietern zusammenwirken können, d.h. zusammenarbeiten, um Anwendungsaufgaben durchzuführen. Die Anwendungsschicht bleibt vollkommen offen für anwendereigene Lösungen.
Ein anderes Konsortium von Firmen, insbesondere Computerfirmen einschließlich Microsoft, startete eine andere Initiative zur Errichtung von einem Netzwerk-Steuerungs-Software-Stack auf der Basis von Internet-Protokollen (IP). Dieses Netzwerksystem wird UPnP (Universelles Plug-and-Play) Netzwerk genannt. Dieses System soll offen für alle Arten von elektronischen Komponenten sein und könnte in ein Netzwerk insbesondere von Personal-Computern integriert werden, aber auch von elektrischen Geräten in einem Haushalt, wie Kühlschränken, Mikrowellenöfen, Steuerung von Heizungen, Klimaanlagen, Sicherheitssystemen, Waschmaschinen und dergleichen. Das UPnP-Netzwerksystem stützt die Steuerung all dieser Geräte über das Internet. Selbst wenn jemand auf Reisen ist, kann er daher die Überwachungssteuerung seiner Heimgeräte handhaben.
Obwohl manchmal sogar HAVi und UPnP als Konkurrenten angesehen werden, was sie in gewisser Weise sind, dienen sie etwas verschiedenen Märkten und haben etwas unterschiedliche Ziele. Es wird daher ein Szenario vorhergesehen, bei dem beide Netzwerke parallel in einem Haushalt existieren, und dass eine Brückenbildung zwischen beiden für den Datenaustausch und ein Zusammenwirken von UPnP-Netzwerkkomponenten und HAVi-Netzwerkkomponenten möglich ist. Dies erfordert jedoch die Erstellung einer Überbrückungstechnologie zwischen HAVi und UPnP-Netzwerken. Wenn man von einer Brücke zwischen UPnP- und HAVi-Netzwerken spricht, bedeutet dies technisch, dass ein Datenpaket zu der anderen Seite über die Datensicherungsschicht übertragen wird. Bei Übertragung eines Datenpakets auf einer höheren Schicht des ISO/OSI-Referenzmodells wird die Übertragungsvorrichtung dann Gateway genannt. Da die Datenpakete von einem HAVi- zu einem UPnP-Netzwerk oder umgekehrt auf einer höheren Schicht übertragen werden, wird die Überbrückungsvorrichtung nachfolgend als Gateway bezeichnet. Dies bedeutet jedoch keine Begrenzung.
Mit dem Gateway zwischen den beiden Netzwerken soll es möglich sein, ein HAVi-Gerät in dem HAVi-Netzwerk aus einem UPnP-Gerät in dem UPnP-Netzwerk zu steuern. Es soll auch unterstützt werden, ein UPnP-Gerät von einem HAVi-Gerät zu steuern.
Für die Steuerung des HAVi-Gerätes von einem UPnP-Gerät ist es erforderlich, die HAVi-Geräte als ein UPnP-Gerät darzustellen. Es müssen hier jedoch besondere Probleme gelöst werden, die nicht Teil der vorliegenden Erfindung sind.
Die Erfindung befasst sich mit dem Problem der Steuerung eines UPnP-Gerätes von einem HAVi-Gerät. Um die Erfindung zu verstehen, ist es von Vorteil, zuerst die Architektur des HAVi-Systems zu erklären. Gemäß der HAVi-Architektur wird ein CE-Gerät in dem Netzwerk über abstrakte Darstellungen des CE-Gerätes gesteuert. Die Architektur erlaubt einem Modul (z.B. Gerätedarstellung, Steuergerät usw.) Befehle oder Steuerinformationen zu einem anderen Modul in dem Heim-Netzwerk zu senden. Ein mit HAVi konformes Gerät enthält Daten (die obige abstrakte Darstellung wird als Gerätesteuer-Modul DCM bezeichnet), die sich auf seine Benutzerschnittstelle und seine Steuerfähigkeiten beziehen. Diese Daten enthalten z.B. einen HAVi-Byte-Code (Java-Code), der von anderen Geräten in dem Netzwerk hochgeladen und ausgeführt werden kann. Ein mit HAVi konformes Gerät hat als Minimum genügend Funktionalität, um mit anderen Geräten in dem HAVi-Netzwerk zu kommunizieren. Während des Zusammenwirkens können Geräte in einer Peer-to-Peer-Weise Steuerdaten und Anwendungsdaten austauschen. Die HAVi-Spezifikation unterscheidet zwischen Steuergeräten und gesteuerten Geräten. Ein Steuergerät ist ein Gerät, das als Host für ein gesteuertes Gerät wirksam ist. Ein Steuergerät dient als Host der abstrakten Darstellung für die gesteuerten Geräte.
Die HAVi-Spezifikation definiert mit HAVi konforme CE-Geräte in den folgenden Kategorien: volle AV-Geräte (FAVs), Zwischen-AV-Geräte (IAVs) und Basis-AV-Geräte (BRVs).
Ein FAV enthält eine vollständige Gruppe von Software-Komponenten der HAVi-Software-Architektur. Ein FAV ist dadurch gekennzeichnet, dass es ein Laufzeitumfeld für HAVi-Byte-Code hat. Dies bedeutet, dass es eine virtuelle JAVA-Maschine hat. Dies ermöglicht einem FAV-Gerät, JAVA-Byte-Code von anderen Geräten herunterzuladen, um zum Beispiel eine verbesserte Tauglichkeit für ihre Steuerung vorzusehen. Ein FAV kann zum Beispiel durch eine mit HAVi konforme Set-Top-Box, einen mit HAVi konformen digitalen Fernsehempfänger oder einen Heim-Personalcomputer gebildet werden. Z.B. kann ein intelligenter Fernsehempfänger das HAVi-Steuergerät für andere mit dem Netzwerk verbundene Geräte sein. Der Empfänger erhält den von einem anderen Gerät in dem Netzwerk hochgeladenen Byte-Code. Ein dieses Gerät darstellendes Symbol kann auf dem Fernseh-Bildschirm sichtbar gemacht werden, und das Zusammenwirken des Benutzers mit dem Symbol kann Elemente des Steuerprogramms veranlassen, das dargestellte Gerät in einer zuvor spezifizierten Weise zu betätigen.
Ein IAV liefert kein Laufzeit-Umfeld für den HAVi-Byte-Code, aber kann eine natürliche Unterstützung für die Steuerung von spezifischen Geräten des Heim-Netzwerkes vorsehen. Ein IAV umfasst eingebettete Software-Elemente, die eine Schnittstelle zur Steuerung allgemeiner Funktionen der spezifischen Geräte vorsehen. Diese Software-Elemente müssen kein HAVi-Byte-Code sein und können als natürliche Anwendungen in dem IAV ausgeführt werden, die natürliche Schnittstellen für den Zugriff zu anderen Geräten verwenden.
Ein BAV kann einen hochladbaren HAVi-Byte-Code vorsehen, bildet aber keinen Host für irgendwelche Software-Elemente der HAVi-Architektur. Ein BAV ist durch einen FAV mittels des früher hochgeladenen Byte-Codes steuerbar. Ein BAV ist durch ein IAV über seinen DCM/FCM steuerbar, der durch ein FAV hochgeladen worden ist. Eine Kommunikation zwischen einem FAV oder einem IAV einerseits und einem BAV andererseits erfordert, dass der HAVi-Byte-Code durch ein FAV instantiiert wird.
Die HAVi-Spezifikation enthält eine Anzahl von Haupt-Software-Elementen, die nachfolgend aufgelistet sind. Für eine ausführlichere Erläuterung dieser Elemente wird auf die HAVi-Spezifikation verwiesen. Eine vorhandene Version der HAVi-Spezifikation ist V1.1, veröffentlicht am 15. Mai 2001 und erhältlich von HAVi, INC., 2694 Bishop Drive, Suite 275 San Ramon, CA 94683, USA.

1. Der 1394 Kommunikations-Medien-Manager (CMM) wirkt als Schnittstelle zwischen den anderen Software-Elementen und dem IEEE 1934-Bus.

Ein Event-Manager (EM) informiert die verschiedenen Software-Elemente über Events in dem Netzwerk, wie Änderungen in der Netzwerk-Konfiguration, die auftreten, wenn Vorrichtungen (Geräte) dem Netzwerk hinzugefügt oder aus diesem entfernt werden.
Ein Register hält Informationen über die mit dem Netzwerk verbundenen Geräte und die Funktionen, die sie anbieten. Geräte können diese Informationen von dem Register erhalten.
Ein Nachrichten-Übermittlungssystem (MS) dient als eine API (Anwendungs-Programmierungs-Schnittstelle), die die Kommunikation zwischen den Software-Elementen der verschiedenen Geräte in dem Netzwerk erleichtert. Das Nachrichtenübermittlungs-System sieht die HAVi-Software-Elemente mit Kommunikationsfähigkeiten vor. Es ist unabhängig von dem Netzwerk und den Transportschichten. Das Nachrichtenübermittlungs-System hat die Aufgabe, Identifizierer für die abstrakten Darstellungen dem FAV oder IAV zuzuordnen. Diese Identifizierer werden zuerst von den abstrakten Darstellungen zur Registrierung bei dem FAV oder IAV benutzt. Dann werden sie von den abstrakten Darstellungen benutzt, um einander innerhalb des Heim-Netzwerkes zu identifizieren. Wenn eine erste abstrakte Darstellung eine Nachricht zu einer anderen abstrakten Darstellung senden möchte, muss sie den Identifizierer der letzteren benutzen, während die Nachrichten übermittelnde API aufgerufen wird.

2. Ein Gerätesteuer-Modul (DCM) stellt ein Gerät in dem Netzwerk dar. Ein Anwendungsprogramm kann unmittelbar mit einem DCM zusammenwirken. Innerhalb von einem DCM kann eine Anzahl von funktionellen Steuermodulen (FCM) enthalten sein. In einem HAVi-Netzwerk wird eine Funktionalität durch einen FCM dargestellt. Hierarchisch gesprochen ist ein FCM immer in einem DCM, ein Gerät darstellend, enthalten. Ein DCM kann mehr als einen FCM enthalten (z.B. enthält ein DCM, der einen digitalen VCR darstellt, einen Tuner-FCM und einen VCR-FCM), aber es gibt nur einen DCM für jedes HAVi-Gerät.
3. Ein DCM-Manager installiert die DCMs. Er reagiert automatisch auf Änderungen in dem Netzwerk durch Installieren neuer DCMs für neue BAV-Geräte.
4. Ein durch Daten gesteuertes Interaktions-(DDI)-Steuergerät rendert GUI (graphische Benutzer-Schnittstelle) in einer Geräteanzeige zugunsten eines HAVi-Software-Elements. Es stützt einen weiten Bereich von Anzeigen, die sich von Graphik zu Nur-Text ändern.
5. Ein Strom-Manager (SMGR) erstellt Verbindungen und leitet Echtzeit-AV-Ströme zwischen zwei oder mehreren Geräten in dem Netzwerk.

Basis-HAVi-Interoperabilität spricht den generellen Bedarf an, dass vorhandenen Geräten erlaubt wird, auf einer Basis-Ebene von Funktionalität zu kommunizieren. Um dies zu erreichen, definiert und benutzt HAVi eine generische Gruppe von Steuer-Nachrichten, die einem Gerät ermöglichen, mit einem anderen Gerät zu kommunizieren, und eine Gruppe von Event-Nachrichten, die vernünftigerweise von einem Gerät seiner Klasse (TV, VCR, DVD-Spieler usw.) erwartet werden sollte. Um diese Lösung zu stützen, ist eine Basisgruppe von Mechanismen erforderlich: Entdeckung des Gerätes, Kommunikation, und eine HAVi-Nachrichtengruppe. Was die Entdeckung der Geräte betrifft: jedes Gerät in dem Heim-Netzwerk benötigt ein gut definiertes Verfahren, das es ihm erlaubt, seine Fähigkeiten anderen anzuzeigen. Die HAVi-Lösung besteht darin, sogenannte SDD-Daten zu verwenden: selbst beschreibende Daten. Die SDD-Daten sind in allen HAVi-Geräten in dem Netzwerk erforderlich. SDD-Daten enthalten Informationen über das Gerät, zu dem von anderen Geräten Zugriff genommen werden kann. Die SDD-Daten enthalten als Minimum genug Informationen, um die Instantiierung eines sogenannten eingebetteten Gerätesteuer-Moduls (eingebetteter DCM) zu erlauben. Ein eingebetteter DCM ist ein Stück eines Codes, der in einem steuernden IAV oder FAV in einem Plattform-abhängigen Code vorinstalliert ist und natürliche Schnittstellen benutzt, um Zugriff zu den IAV- oder FAV-Resourcen zu nehmen. Wie oben erwähnt wurde, ist ein DCM für ein Gerät ein Software-Element, das eine Schnittstelle zur Steuerung von allgemeinen Funktionen des Gerätes vorsieht. Die Instantiierung eines eingebetteten DCM führt zur Registrierung der Gerätefähigkeiten bei einem Register. Das Register sieht einen Leitfaden-Service vor und ermöglicht einem Objekt in dem Netzwerk, ein anderes Objekt in dem Netzwerk zu lokalisieren. Die Registrierung erlaubt Anwendungen, die Basisgruppe von Befehlsnachrichten herzuleiten, die zu einem bestimmten Gerät in dem Netzwerk gesendet werden können.
Was die Kommunikation anbetrifft: nachdem eine Anwendung die Fähigkeiten eines Gerätes bestimmt hat, muss die Anwendung zu diesen Fähigkeiten Zugriff nehmen können. Dies erfordert eine allgemeine Kommunikationsfähigkeit, die Anwendungen erlaubt, Anfragen an Geräte auszugeben. Der Service wird durch die HAVi-Nachrichtenübermittlungs-Systeme und DCMs vorgesehen. Die Anwendung sendet HAVi-Nachrichten an DCMs, und das DCM beschäftigt sich dann mit der Kommunikation mit den Geräten.
Was die HAVi-Nachrichtengruppen angeht: um die Basis-Interoperabilität zu stützen, ist eine gut definierte Gruppe von Nachrichten erforderlich, die von allen Geräten einer bestimmten bekannten Klasse gestützt werden muss (z.B. der Klasse von Fensehempfängern, der Klasse von Video-Kassettenrecordern, der Klasse von DVD-Spielern usw.). Dies gewährleistet, dass ein Gerät mit vorhandenen Geräten ebenso wie mit zukünftigen Geräten unabhängig von dem Hersteller arbeiten kann. Diese drei Basis-Erfordernisse stützen einen bestimmten minimalen Pegel an Interoperabilität. Da jedes Gerät die Fähigkeiten eines anderen Gerätes über das Register abfragen kann, kann jedes Gerät die von einem anderen Gerät gestützte Nachrichtengruppe bestimmen. Da Anwendungen Zugriff zu dem Nachrichtenübermittlungs-System haben, kann jedes Gerät mit einem anderen Gerät zusammenwirken.
Die Basis-HAVi-Interoperabilität gewährleistet, dass Geräte auf einem Basis-Pegel an Funktionalität miteinander zusammenwirken können. Jedoch wird ein erweiterter Mechanismus benötigt, um auch einem Gerät zu erlauben, mit anderen Geräten mit jeder zusätzlichen Funktionalität zu kommunizieren, die in den eingebetteten DCMs in einem FAW nicht vorhanden ist. Zum Beispiel können eingebettete DCMs nicht alle Merkmale von bestehenden Produkten stützen und werden wahrscheinlich nicht jene völlig neuen und zukünftigen Produktkategorien stützen.
HAVi-, Level 2'-Interoperabilität sieht diesen Mechanismus vor. Um dies zu erreichen, erlaubt die HAVi-Architektur, hochladbare DCMs als Alternative zu sogenannten eingebetteten Geräte-Steuer-Modulen. Ein hochladbarer DCM kann durch jede geeignete Quelle vorgesehen werden, aber eine wahrscheinliche Technik besteht darin, den hochladbaren DCM in den HAVi-SDD-Daten in dem DAV-Gerät zu platzieren und von dem BAV zu dem FAV-Gerät hochzuladen, wenn das BAV mit dem Heim-Netzwerk verbunden ist. Da die HAVi-Architektur Lieferanten-neutral ist, ist es erforderlich, dass der hochgeladene DCM in einer Vielfalt von FAV-Geräten arbeitet, die alle potentiell verschiedene Hardware-Architekturen aufweisen. Um dies zu erreichen, werden hochgeladene DCMs in HAVi-(Java)-Byte-Code ausgeführt. Das Java-Byte-Code-Laufzeit-Umfeld in FAV-Geräten stützt die Instantiierung und Ausführung von hochgeladenen DCMs. Nach Erstellen und Laufen in einem FAV-Gerät kommuniziert der DCM mit den BAV-Geräten in derselben Weise wie oben beschrieben.
Wenn unter dem neuen Szenario ein HAVi-Netzwerk mit einem UPnP-Netzwerk über ein Gateway verbunden wird und ein UPnP-Gerät von einem HAVi-FAW-Gerät gesteuert werden soll, tritt das zusätzliche Problem auf, dass keines der UPnP-Geräte einen HAVi-DCM vorsieht, der auf das HAVi-FAV-Gerät hochgeladen werden könnte. Daher ist weder Basis- noch Level-2-Interoperabilität für die Steuerung von UPnP-Geräten von einer HAVi-Netzwerkstation verfügbar.
Aus WO-A-02/09384 ist eine HAVi-Nicht-Havi-Netzwerkbrücke bekannt, in der vorgeschlagen wird, Softwaremittel in der Brücke vorzusehen, die eine Übersetzung von UPnP-Service-Beschreibungen in HAVi-DDI-Daten ausführen.
Aus WO-A-01/01632 ist eine HAVi-Nicht-Havi-Netzwerkbrücke bekannt, in der vorgeschlagen wird, eine Software-Element-Fabrik in dem Gateway vorzusehen, die einen HAVi-DCM für die Steuerung einer Nicht-HAVi-Netzwerkstation erzeugen kann.
Erfindung
Der Erfindung liegt die Aufgabe zugrunde, das Problem der Steuerung eines nicht mit HAVi-konformen Gerätes in einem Nicht-HAVi-Netzwerk von einem mit HAVi konformen FAV-Gerät in einem HAVi-Netzwerk-Gateway zu steuern. Bei einigen der UPnP-Geräte könnte in der Gateway-Vorrichtung eine entsprechende Darstellung in Form eines DCM mit einem eingebetteten gerätespezifischen FCM vorhanden sein. Dieser DCM/FCM könnte zur Erzeugung einer Benutzer-Schnittstelle in dem HAVi-FAV-Gerät zur Steuerung des UPnP-Gerätes unter Verwendung von Basis-Interoperabilität verwendet werden. Der Benutzer könnte daher Steuerbefehle für das UPnP-Gerät erzeugen, die in dem Gateway interpretiert und in einen entsprechenden UPnP-Befehl umgeformt werden müssen, der in dem zu steuernden UPnP-Gerät verstanden würde.
Ein Problem besteht jedoch darin, dass es bestimmte UPnP-Geräte gibt, für die keine entsprechende Darstellung in Form eines FCN in dem HAVi-System existiert. Für solch einen Fall wird in dem HAVi-System die Möglichkeit ausgeführt, einen sogenannten generischen FCM zu erzeugen. Im Fall eines unbekannten UPnP-Gerätes kann der Gateway nur einen DCM vorsehen, in dem ein generischer FCM für die Steuerung des UPnP-Gerätes eingebettet ist. Mit diesem generischen FCM kann das HAVi-FAV-Gerät keine Benutzer-Schnittstelle erzeugen, weil keine der Funktionen des UPnP-Gerätes in dem generischen FCM bekannt ist. Dies ist die Crux des der Erfindung zugrunde liegenden Problems.
Die Erfindung löst dieses Problem mit den Mitteln der unabhängigen Ansprüche 1, 7, 10 und 13. Die Erfindung verwendet die Möglichkeit in dem HAVi-System, von einem DCM ein sogenanntes HAVLET herunterzuladen, das ein ausführbarer JAVA-Byte-Code ist, um eine Benutzer-Schnittstelle in dem HAVi-Steuergerät zu erzeugen. Dieses HAVLET-Software-Stück wirkt mit dem DCM für die Nicht-HAVi- Geräte zusammen, die in dem Gateway gespeichert und ausgeführt werden. Der Nicht-HAVi-DCM enthält eine spezialisierte Nicht-HAVi-FCM, die die Software-Routinen zur Anforderung der Funktionsbeschreibung eines Nicht-HAVi-Gerätes und zu ihrer Zuführung zu dem HAVi-FAV-Gerät enthält. Das in dem HAVi-FAW-Gerät laufende HAVLET nimmt die Funktionsbeschreibungen des Nicht-HAVi-Gerätes und erzeugt eine entsprechende Benutzer-Schnittstelle mit diesen Funktionsbeschreibungen.
Vorteilhafte Modifikationen und Verbesserungen der Erfindung sind in den Unteransprüchen aufgelistet. Es ist sehr vorteilhaft, wenn der in dem Gateway betriebene FCM Mittel zur Übersetzung der Funktionsbeschreibungen, die aus dem Nicht-HAVi-Gerät (23) gelesen werden, in eine Datenform umfasst, die von dem HAVi-System gestützt wird, bevor die Zuführung zu dem HAVi-Steuergerät erfolgt. Diese Verbesserung vereinfacht die HAVLET-Software, die in dem HAVi-Steuergerät betrieben wird, sehr stark. Die Mittel zur Übersetzung der Funktionsbeschreibung des Nicht-HAVi-Gerätes müssen in dem HAVLET nicht enthalten sein, so dass es nicht notwendig ist, einen entsprechenden Software-Code in das HAVi-FAV-Gerät hochzuladen, wodurch die Speichererfordernisse in dem HAVi-FAV-Gerät vermindert werden. In gleicher Weise wird der Prozessor des HAVi-FAV-Gerätes entlastet.
Die Erfindung kann am besten verwendet werden, wenn ein HAVi-Netzwerk mit einem Netzwerk auf IP-Basis kombiniert werden soll, z.B. dem UPnP-Netzwerk. Im Falle eines UPnP-Netzwerkes wird ein UPnP-Gerät mittels sogenannter XML-Beschreibungen für jede Funktion eines UPnP-Gerätes dargestellt. Die XML-Beschreibungen werden von dem spezialisierten Funktions-Steuermodul angefordert, der vom Typ eines generischen FCM ist (gemäß der HAVi-Spezifikation), der in dem Gateway betrieben, übersetzt und dann dem HAVLET zugeführt wird, der von dem HAVi-Steuergerät ausgeführt ist. Für jede übersetzte Funktionsbeschreibung erzeugt das HAVLET eine graphische Darstellung vorzugsweise in Form einer Taste, eines Schiebers, einer Fragetaste oder eines Eingangsfeldes zusammen mit einem Symbol oder einem Ausdruck, der die Bedeutung erklärt.
Ein Gateway gemäß der Erfindung ist in dem unabhängigen Anspruch 7 beansprucht.
Der unabhängige Anspruch 10 beansprucht ein Computer-Programmprodukt, nämlich ein Funktions-Steuermodul FCM für den Gateway gemäß der Erfindung.
Der unabhängige Anspruch 13 beansprucht ein Computer-Programmprodukt, insbesondere HAVLET, das in dem erfindungsgemäßen HAVi-Steuergerät betrieben wird.
Zeichnungen
Ausführungsbeispiele der Erfindung sind in den Zeichnungen dargestellt und werden in größeren Einzelheiten in der nachfolgenden Beschreibung erläutert.
In den Figuren zeigen:
1 ein Beispiel eines HAVi-Netzwerks und eines UPnP-Netzwerkes, die miteinander über einen Gateway verbunden sind;
2 die Basis-Software-Elemente, die miteinander von dem UPnP-Gerät, dem Gateway und dem HAVi-Steuergerät zusammenwirken, und;
3 ein Beispiel einer Benutzer-Schnittstelle für die Steuerung einer UPnP-Sicherheitskamera, die auf dem HAVi-Steuergerät angezeigt wird.
Ausführungsbeispiele der Erfindung
1 zeigt den prinzipiellen Aufbau von zwei Netzwerken, die miteinander über einen Gateway 10 verbunden sind. Auf der linken Seite von 1 ist ein UPnP-Netzwerk dargestellt. Als Beispiel bezeichnet die Bezugsziffer 21 eine Waschmaschine, die Bezugsziffer 22 einen Kühlschrank, die Bezugsziffer 23 eine Sicherheitskamera, die Bezugsziffer 24 eine Heizungs-Steuereinheit, und die Bezugsziffer 25 einen Personal-Computer mit einem ISDN/DSL-Internet-Anschluss. Alle diese UPnP-Geräte sind mit einem Ethernet-Datenbus 20 für den Datenaustausch verbunden. Die Ethernet-Bus-Leitungen sind auch mit dem Gateway 10 verbunden. Auf der rechten Seite von 1 ist ein HAVi-Netzwerk dargestellt. Die Bezugsziffer 31 bezeichnet ein Fernsehgerät, die Bezugsziffer 32 einen Video-Kassettenrecorder, die Bezugsziffer 33 einen DVD-Spieler und die Bezugsziffer 34 steht für eine Set-Top-Box, z.B. einen digitalen Satellitenempfänger. Die HAVi-Netzwerkstationen sind mit einem IEEE 1394-Bus 30 für den Datenaustausch verbunden. Der Gateway 10 ist auch mit dem 1394-Bus 30 verbunden. Der Gateway 10 umfasst ein IP-Protokoll-Profil 11 an einer Seite, ein HAVi-Protokoll-Profil 12 auf der anderen Seite wie auch Software zur Ausführung der Übersetzung oder Zuordnung von Steuernachrichten und Events von einem Netzwerk zu dem anderen.
Die HAVi – wie auch UPnP-Spezifikationen sind in der Fachwelt bekannt. Daher besteht keine Notwendigkeit, alle Einzelheiten in diesen Spezifikationen zwecks Offenbarung der vorliegenden Erfindung zu erklären. Es wird daher ausdrücklich auf die HAVi-Spezifikation wie auch auf die UPnP-Spezifikation für diesen Zweck hingewiesen. Die UPnP-Spezifikation kann von dem UpnP-Forum erhalten werden, das von der Microsoft-Incorporation genanagt wird.
Wie zuvor erwähnt wurde, beruht das UPnP-Netzwerksystem auf den vorhandenen Internet-Protokollen. Eine graphische Benutzer-Schnittstelle (GUI) zur Steuerung von UPnP-Geräten von einem UPnP-Steuergerät, z.B. einem Personal-Computer 25, kann aus einer Mehrzahl von Symbolen bestehen, die auf dem Computer-Monitor angezeigt werden. Wenn ein Benutzer ein Symbol wählt, werden die HTML-Seiten von dem fraglichen Gerät wiedergewonnen. Die HTML-Seiten werden für den Benutzer angezeigt. Dies erlaubt dem Benutzer, das gegebene Gerät zu steuern. In der UPnP-Spezifikation ist definiert, dass jedes UPnP-Gerät eine Liste von Diensten umfasst, die von dem Gerät geliefert werden. Jeder dieser Dienste ist in einem XML-Dokument beschrieben, wobei XML für Erweiterungs-Dokumenten-Auszeichnungssprache (extension mark-up language) steht, d.h. Internet-Technologie. Jedes XML-Dokument enthält eine ausführliche Beschreibung von allen Steuermöglichkeiten innerhalb von dem Service. Diese XML-Dokumente werden zur Steuerung eines UPnP-Gerätes von einem HAVi-Steuergerät benutzt.
Der Steuerungsprozess des UPnP-Gerätes von einem HAVi-FAV-Gerät ist in 2 veranschaulicht. Identische Bezugsziffern bezeichnen gleiche Komponenten wie in 1 gezeigt und brauchen nicht erneut erläutert zu werden. In 2 ist die Ethernet-Schnittstellenschaltung 26, mit der UPnP-Geräte wie auch der Gateway ausgerüstet sind, getrennt dargestellt. In gleicher Weise sind die 1394-Bus-Schnittstelle 35 für die HAVi-Netzwerk-Komponenten und der Gateway 10 dargestellt. Zusätzlich zu den Basis-Software-Elementen der Sicherheitskamera 23 sind der Gateway 10 und das Fernsehgerät 31 in 2 gezeigt. Eine Sicherheitskamera 23 enthält ein XML-Dokument, in dem die Steuermöglichkeiten für die Sicherheitskamera aufgelistet sind. Das wichtige Software-Element des Gateway ist ein Geräte-Steuermodul DCM, der einen spezifizierten Funktionssteuer-Modul FCM wie auch ein ausführbares JAVA-Programm HAVLET enthält. Das JAVA-Programm-HAVLET ist für ein Hochladen zu einem HAVi-FAV-Gerät während der Konfigurationsphase des HAVi-Netzwerks vorgesehen. Daher betrifft das sehr wichtige Software-Element des HAVi-Steuergerätes 21 dieses HAVLET.
Zur Steuerung der Sicherheitskamera 23 wirkt der Gateway mit der Sicherheitskamera 23 und dem Fernsehgerät 31 wie folgt zusammen.
Nach Beendigung der Konfigurationsphase in beiden Netzwerken können alle Netzwerkskomponenten innerhalb des HAVi-Netzwerks wie auch in dem UPnP-Netzwerk von dem Fernsehgerät 31 gesteuert werden. Eine Benutzer-Schnittstelle zur Steuerung dieser Geräte ist in Form einer Liste von Symbolen für jedes steuerbare Gerät eingebaut. Der Kommunikations-Medien-Manager CMM, der Event-Manager EM, das Register und das Nachrichtenübermittlungs-System MS des HAVi-Steuer-Profils, die zum Sammeln der Informationen von allen steuerbaren Elementen verwendet werden, sei es in dem HAVi-Netzwerk oder in den UPnP-Netzwerken. Natürlich enthält der Gateway 10 entsprechende Software-Elemente und Schnittstellen, so dass die Zuordnung der UPnP-Geräte in dem HAVi-Register möglich ist. Von diesem Prozess wird jedoch vorausgesetzt, dass er Stand der Technik ist, und er wird hier daher nicht in größeren Einzelheiten erläutert.
Ein Benutzer kann nun wünschen, die Sicherheitskamera von dem Fernsehgerät 31 in dem HAVi-Netzwerk zu steuern. Zu diesem Zweck wählt er das entsprechende Symbol auf dem Fernsehschirm. Dieses Ereignet startet das Herunterladen des HAVLETS in den internen Speicher des Fernsehgerätes 31. Gleich nach dem Herunterladen wird die Ausführung des HAVLETS gestartet. Das HAVLET ist ein ausführbares JAVA-Programm. Da JAVA eine Plattform-unabhängige Programmierungssprache ist, läuft es in jedem HAVi-FAV-Gerät, das ein Laufzeit-Umfeld für JAVA-Byte-Code hat.
Drittens sendet das ausgeführte HAVLET eine Anforderung zur Wiedergewinnung von Informationen über die Sicherheitskamera 23 an den Gateway 10. Diese Anforderung wird von dem laufenden UPnP-Funktionssteuer-Modul FCM akzeptiert, der selbst das XML-Dokument/e wiedergewinnt, das bzw. die in dem Webserver der Sicherheitskamera 23 gespeichert sind. Jedes XML-Dokument enthält Beschreibungen der Steuermöglichkeiten für die Sicherheitskamera 23. Der FCM übersetzt die XML-Beschreibungen in ein Struct (eine Gruppe von Variablen) und führt sie dem HAVLET zu, das in dem Fernsehgerät 31 läuft. Das HAVLET nimmt dann diese Funktionsbeschreibungen und erzeugt für jedes steuerbare Element eine graphische Darstellung z.B. als Taste, Schieber, Anfragetaste, Eingabefeld oder dergleichen, um die graphische Benutzer-Schnittstelle für die Steuerung der Sicherheitskamera auf dem Fernsehschirm zu erzeugen. Der Informationsfluss ist in 2 mit Pfeilen dargestellt, und die Bezifferung drückt die Reihenfolge der Zusammenwirkung aus.
Die graphische Benutzer-Schnittstelle für die Sicherheitskamera 23 ist in 3 dargestellt. Für jedes steuerbare Element der Sicherheitskamera wird eine graphische Darstellung erzeugt, z.B. ist für die Helligkeitseinstellung ein Schieber auf dem Fernsehschirm dargestellt. Mit einem Maus-Zeiger kann die Helligkeit direkt mittels der Links-Rechts-Tasten gesteuert werden, die an der linken und rechten Seite des Schiebers positioniert sind. Auch der Schieber selbst kann zu der gewünschten Position geschoben werden, was aus einer großen Vielfalt von Computermenüs bekannt ist. An der linken Seite des Schiebers für die Helligkeits-Einstellung ist der Ausdruck Setze Helligkeit schriftlich gezeigt. Dieser Ausdruck wird direkt von der XML-Beschreibung für dieses steuerbare Element übernommen. Der in dem Gateway laufende FCM weiß nicht notwendigerweise die Bedeutung dieses Ausrucks. Dies ist offensichtlich, wenn jemand betrachtet, dass ein neuer Produkt-Typ in das UPnP-Netzwerk integriert werden kann, von dem heute keiner weiß, was die steuerbaren Elemente sind. In einem solchen Fall muss der Benutzer selbst die richtige Interpretation dieses steuerbaren Elements vornehmen. Unterhalb des Helligkeitsschiebers ist eine Erhalte-Helligkeits-Taste positioniert. Dies ist ein Beispiel einer Anfragetaste. Durch Drücken dieser Anfragetaste wird der gegenwärtig gesetzte Helligkeitswert ausgelesen und neben der Taste angezeigt. Unterhalb der Taste zum Erhalten der Helligkeit sind einfache Tasten zum Erhöhen und Vermindern der Helligkeit positioniert. Diese Tasten haben die gleiche Wirkung wie die rechten und linken Tasten des Schiebers zum Setzen der Helligkeit. Ein Beispiel eines Eingangsfeldes ist die Feld-Setz-Standard-Drehung. Hier wird bei diesem Feld eine Nummer angefordert und soll in die Eingangsmaske eingegeben werden. Der Eingangs-Parameter bestimmt die Drehung der Sicherheitskamera zum Erlangen einer anderen Ansicht. Anstatt der Anzeige des herausgezogenen Ausdrucks für das von der XML-Beschreibung abgeleitete entsprechende Steuerelement könnte ein selbst erklärendes Symbol in der Benutzer-Schnittstelle angezeigt werden. Dies erfordert jedoch die Notwendigkeit, dass vor-definierte Benutzer-Schnitt-stellen-Komponenten in dem HAVLET für die verschiedenen Dienste der verschiedenen möglichen UPnP-Geräte installiert sind. Selbst wenn ein neuer Typ eines Gerätes in das UPnP-Netzwerk integriert wird, könnte die vor-definierte Benutzer-Schnittstellen-Komponente verwendet werden, wenn dieses neue Gerät einen Dienst vorsieht, für den die Benutzer-Schnittstellen-Komponenten bereits in dem HAVLET vorgesehen sind. Für unbekannte Dienste würde diese Lösung jedoch nicht arbeiten. Eine andere Lösung besteht darin, dass es eine Mischung von beiden verschiedenen Lösungen für einen Dienst gibt. Für alle Parameter in der XML-Beschreibung, denen bereits ein Symbol zugeordnet worden ist, könnte ein entsprechendes Symbol in der Benutzer-Schnittstelle angezeigt werden. Für die unbekannten Parameter brauchen die entsprechenden Ausdrücke jedoch nicht gezeigt zu werden.
Das XML-Dokument eines UPnP-Gerätes kann als Norm-Ausführung der UPnP-Spezifikation angesehen werden. Für die Realisierung der vorliegenden Erfindung muss hier keine außergewöhnliche Programmierung vorgenommen werden. Die Basis-Software-Elemente für die Realisierung der vorliegenden Erfindung sind der UPnP-FCM, der in dem Gateway läuft, und das in das HAVi-FAW-Gerät hochgeladene HAVLET. Beide Software-Elemente enthalten außerordentliche Routinen für die Realisierung der Erfindung.
Es gibt einen Funktions-Steuermodul für das UPnP-Netzwerk. Es ist irgendwie ein ,generischer' FCM, der immer für die Steuerung jedes UPnP-Geräts verwendet wird. Die Programmiersprache ist JAVA. Dies ist eine allgemein bekannte Programmiersprache, die verbreitet benutzt wird, so dass die besondere Syntax hier nicht erklärt werden muss. Eine Routine zum Herausziehen der Dienste aus dem XML-Dokument ist enthalten. Diese Routine zieht daher heraus, welche Art von Service das angeforderte UPnP-Gerät anbietet. Zum Beispiel bietet die UPnP-Sicherheitskamera den Service an, einen Strom von Videobildern in einem besonderen Format wie JPEG oder Image bei einem bestimmten Kompressionspegel und einer bestimmten Auflösung zu liefern.
Eine Erhalte-Service-Beschreibungs-Routine fordert die Information an, wie viele Dienste das UPnP-Gerät anbietet. Mit einer Erhalte-Service-Informationslisten-Routine kann die Information über jede Steuermöglichkeit von dem ausgewählten Service wiedergewonnen werden. Eine Routine Führe-Steuerbefehl-aus ist zum Senden eines Steuerbefehls an ein UPnP-Gerät vorgesehen. Eine Routine Führe-Geräte-variable-Anfrage-aus ist zur Wiedergewinnung des gegenwärtigen variablen Wertes von einem UPnP-Gerät vorgesehen. Diese Routinen werden auf Anfrage von dem HAVLET ausgeführt, der in dem HAVi-Gerät läuft.
Für den Routine-Ablauf werden entsprechende Instruktionen in dem zweiten Teil der Programm-Auflistung gehalten. Es wird ausdrücklich auf einen Routine-Ablauf Erhalte-Service-Beschreibung und Erhalte-Service-Informationsliste Bezug genommen. Eine weitere wichtige Routine für die Ausführung der Erfindung ist ein Routine-Sende-Steuerbefehl zum Senden eines Steuerbefehls an das UPnP-Gerät. Innerhalb dieser Routine wird auch eine Antwort-Nachricht abgeschätzt und dem HAVLET in dem HAVi-Gerät zugeführt. Wichtig für die Ausführung der Erfindung ist auch eine Routine Frage-Nach-Geräte-Variabler. Diese Routine wird gestartet, wenn das HAVLET eine entsprechende Anforderung gesendet hat. Wenn zum Beispiel der Benutzer eine Anfragetaste gedrückt hat, wird diese Routine aufgerufen. Wiederum wird in dieser Routine eine Antwort-Nachricht zu dem HAVi-Gerät zurückgesendet. Mit einer Routine Empfange-http-Notify-Daten werden UPnP-Events gehandhabt.
Der JAVA-Quellen-Code einer HAVLET-Ausführung der Erfindung ist nicht dargestellt. Die Hauptaufgabe des HAVLETS ist der Aufbau der Benutzer-Schnittstelle zur Steuerung eines UPnP-Gerätes. Das HAVLET enthält entsprechende Routinen zum Erhalten der Service-Beschreibungen für ein UPnP-Gerät, um die Service-Informationsliste zur Ausführung eines Steuerbefehls zu erhalten, und um eine gerätevariable Anfrage auszuführen.
Der Funktionssteuer-Modul ist in einem Geräte-Steuerungs-Modul gemäß der HAVi-Spezifikation integriert. Was daher getan werden muss, ist die Programmierung eines Gerätesteuer-Moduls, in dem der Funktionssteuer-Modul eingebettet ist, wie oben erwähnt. Dieses Programm wird als Standard-Ausführung der HAVi-Spezifikation angesehen, die nicht in Einzelheiten erläutert werden muss.
Der Teil des Programms, der die Übersetzung der XML-Beschreibungen in eine Datenform ausführt, die von dem HAVi-System gestützt wird, ist in einer Routine enthalten, die Service-Beschreibungs-Routine genannt wird. Die XML-Beschreibungen sind grundsätzlich im Textformat. Diese XML-Beschreibungen werden abgeschätzt. Zum Beispiel schätzt ein Programmteil ab, ob die XML-Beschreibungen einige Aktionen enthalten. Diese Aktionen entsprechen den steuerbaren Elementen des UPnP-Gerätes. Sie werden in die HAVi-typische Form einer mit ,Struct' bezeichneten variablen Gruppe übersetzt. Dies wird durch Analysieren der XML-Beschreibung und Speichern aller interessierenden Informationen in den örtlichen Feldern durchgeführt.

Claims

Verfahren zur Erzeugung einer Benutzer-Schnittstelle in einem HAVi-Gerät für die Steuerung eines Nicht-HAVi-Gerätes, wobei HAVi für Heim-Audio-Video-Interoperabilität steht, wobei das HAVi-Gerät (31) eine Station eines HAVi-Netzwerks und das Nicht-HAVi-Gerät (23) eine Station eines Nicht-HAVi-Netzwerks ist, und wobei beide Netzwerke miteinander durch eine Gateway-Vorrichtung (10) verbunden sind, dadurch gekennzeichnet, dass die Gateway-Vorrichtung (10) ein HAVi-Funktionssteuer-Modul (FCM) für die Nicht-HAVi-Geräte betreibt, der die Beschreibungen der Funktionen des zu steuernden Nicht-HAVi-Gerätes (23) anfordert und sie dem HAVi-Gerät (31) zuführt, das die entsprechenden Benutzer-Schnitt-stellen-Komponenten für die Funktionen des Nicht-HAVi-Gerätes (23) mittels eines JAVA-Programms (HAVLET) erzeugt, das in dem HAVi-Gerät (31) abläuft, wobei die Gateway-Vorrichtung (10) das JAVA-Programm (HAVLET) auf das HAVi-Gerät (31) hochlädt.
Verfahren nach Anspruch 1, bei dem der Funktionssteuer-Modul (FCM) die aus dem Nicht-HAVi-Gerät (23) gelesenen Funktionsbeschreibungen in eine Datenform übersetzt, die von dem HAVi-System gestützt ist, bevor die Zuführung zu dem HAVi-Gerät (31) erfolgt.
Verfahren nach Anspruch 1, bei dem das JAVA-Programm (HAVLET) die aus dem Nicht-HAVi-Gerät (23) gelesenen Funktionsbeschreibungen in eine von dem HAVi-System gestützte Datenform übersetzt.
Verfahren nach einem der vorherigen Ansprüche, bei dem das HAVi-Gerät (31), in dem die Benutzer-Schnittstelle zur Steuerung des Nicht-HAVi-Gerätes (23) erzeugt wird, ein HAVi-Gerät des FAV-Typs ist, wobei FAV volles Audio/Video-HAVi-Gerät bedeutet.
Verfahren nach einem der vorherigen Ansprüche, bei dem das Nicht-HAVi-Netzwerk ein Netzwerk auf IP-Basis ist, insbesondere ein UPnP-Netzwerk, wobei UPnP für universelles Plug-and-Play-Netzwerksystem steht.
Verfahren nach Anspruch 5, bei dem die Funktionsbeschreibungen des Nicht-HAVi-Gerätes (23) XML-Beschreibungen sind, wobei XML für Erweiterungs-Auszeichnungssprache (Extension Mark-Up Language) steht.
Gateway-Vorrichtung zur Verwendung bei einem Verfahren gemäß einem der vorhergehenden Ansprüche, umfassend eine Schnittstelle (35) für ein HAVi-Netzwerk und eine Schnittstelle (26) für ein Nicht-HAVi-Netzwerk, dadurch gekennzeichnet, dass die Gateway-Vorrichtung (10) einen HAVi-Funktionssteuer-Modul (FCM) umfasst, der Mittel zum Anfordern der Funktionsbeschreibungen eines Nicht-HAVi-Gerätes (23) und Mittel zum Zuführen der Funktionsbeschreibungen zu der Netzwerkstation des HAVi-Netzwerks enthält, in dem eine Benutzer-Schnittstelle zur Steuerung des Nicht-HAVi-Gerätes (23) erzeugt werden soll, und der ferner ein JAVA-Programm (HAVLET) umfasst, das Mittel zur Erzeugung einer Benutzer-Schnittstelle mit den Funktionsbeschreibungen des Nicht-HAVi-Gerätes (23) enthält, wobei das JAVA-Programm (HAVLET) für eine Hochladung in ein HAVi-Gerät (31) vorgesehen ist.
Gateway nach Anspruch 7, bei dem der Funktionssteuer-Modul (FCM) Mittel zum Übersetzen der aus dem Nicht-HAVi-Gerät (23) gelesenen Funktionsbeschreibungen in eine von dem HAVi-System gestützte Datenform umfasst, bevor die Zuführung zu dem HAVi-Netzwerk erfolgt.
Gateway nach Anspruch 7, bei dem das JAVA-Programm (HAVLET) Mittel zum Übersetzen der aus dem Nicht-HAVi-Gerät (23) gelesenen Funktionsbeschreibungen in eine von dem HAVi-System gestützte Datenform umfasst.
Computer-Programm-Produkt in Form eines HAVi-Funktionssteuer-Moduls (FCM), der direkt in den internen Speicher einer Gateway-Vorrichtung (10) geladen werden kann, gemäß einem der Ansprüche 7 bis 9, umfassend Mittel zum Anfordern von Funktionsbeschreibungen eines Nicht-HAVi-Gerätes und Mittel zum Zuführen der Funktionsbeschreibungen zu einer Netzwerkstation eines HAVi-Netzwerks, in dem eine Benutzer-Schnittstelle zur Steuerung des Nicht-HAVi-Gerätes (23) erzeugt werden soll, wenn das Produkt von einem Prozessor der Gateway-Vorrichtung (10) ausgeführt wird.
Computer-Programm-Produkt nach Anspruch 10, das Mittel zum Übersetzen der aus dem Nicht-HAVi-Gerät (23) gelesenen Funktionsbeschreibungen in eine von dem HRVi-System gestützte Datenform umfasst, bevor die Zuführung zu dem HAVi-Netzwerk erfolgt.
Computer-Programm-Produkt nach Anspruch 10 oder 11, bei dem die Funktionsbeschreibungen des Nicht-HAVi-Gerätes (23) XML-Beschreibungen sind, wobei XML für Erweiterungs-Auszeichnungssprache steht.
Computer-Programm-Produkt in Form eines JAVA-Programms (HAVLET), das direkt in den internen Speicher eines HAVi-Gerätes (31) eines HAVi-Netzwerks geladen werden kann, umfassend Mittel zur Erzeugung einer Benutzer-Schnittstelle für die Steuerung eines Nicht-HAVi-Gerätes (23) mit den von dem Nicht-HAVi-Gerät (23) wiedergewonnenen Funktionsbeschreibungen, wenn das Produkt von einem Prozessor des HAVi-Gerätes (31) ausgeführt wird.
Computer-Programm-Produkt nach Anspruch 13, bei dem die wiedergewonnenen Funktionsbeschreibungen übersetzte XML-Beschreibungen des Nicht-HAVi-Gerätes (23) sind, wobei XML für Erweiterungs-Auszeichnungssprache steht, und die XML-Beschreibungen in eine von dem HAVi-System gestützte Datenform übersetzt werden.
Computer-Programm-Produkt nach Anspruch 13, das Mittel zum Übersetzen der aus dem Nicht-HAVi-Gerät (23) wiedergewonnenen Funktionsbeschreibungen in eine von dem HAVi-System gestützte Datenform umfasst und die Funktionsbeschreibungen XML-Beschreibungen sind, wobei XML für Erweiterungs-Auszeichnungssprache steht.
Computer-Programm-Produkt nach einem der Ansprüche 13 bis 15, bei dem die Mittel zur Erzeugung einer Benutzer-Schnittstelle Mittel umfassen, um einer übersetzten Funktionsbeschreibung die zugehörige graphische Darstellung zusammen mit einem Symbol oder einem Ausdruck zuzuordnen, der die Bedeutung der Funktionsbeschreibung erklärt.
Computer-Programm-Produkt nach Anspruch 16, bei dem die graphische Darstellung die Form einer Taste, eines Schiebers, einer Fragetaste oder eines Eingabefeldes hat.