DE10304993B4

DE10304993B4 - Verfahren zum Darstellen von Bedienoberflächen auf einem Display eines elektronischen Gerätes

Info

Publication number: DE10304993B4
Application number: DE2003104993
Authority: DE
Inventors: Ulrich Dipl.-Ing. Haderdauer (FH)
Original assignee: Loewe Opta GmbH
Current assignee: Loewe Ip Holding Ltd Cy
Priority date: 2003-02-07
Filing date: 2003-02-07
Publication date: 2008-06-19
Anticipated expiration: 2023-02-08
Also published as: DE10304993A1

Abstract

Verfahren zum Darstellen mindestens einer Bedienoberfläche auf einem Display eines ersten elektronischen Gerätes und zum Bedienen mindestens eines zweiten elektronischen Gerätes anhand der Bedienoberfläche, die unter Verwendung eines Mikroprozessors und einer OSD-Anzeigeschaltung generiert wird, wobei die Geräte an einen drahtgebundenen oder drahtlosen Bus angeschlossen sind, wobei die Geräte insbesondere Geräte der Unterhaltungselektronik sind und wobei eine einheitliche XML-basierende Auszeichnungssprache für die Bedienoberflächen aller miteinander kommunizierenden ersten und zweiten Geräte verwendet wird, gekennzeichnet durch
– Entkopplung der grafischen Darstellung (View) von einem Datenmodell (Model) im steuerbaren Teil des ersten Gerätes mindestens zur kontextabhängigen Präsentation von graphischen Bedienelementen auf dem Display;
– Errichtung einer Oberflächenbibliothek in einem Speicher im ersten Gerät durch Zuführen der graphischen Darstellungen (Views) und Datenmodelle (Models) sowie Erstellen von deren Verknüpfungen mittels Mikrocomputer, wobei die graphischen Darstellungen (Views) den graphischen Aufbau der Bedienelemente und deren Platzierung auf der Bedienoberfläche im ersten Gerätes festlegen und dort gespeichert...

Description

Die Erfindung betrifft ein Verfahren zum Darstellen von Bedienoberflächen auf einem Display eines ersten elektronischen Gerätes, insbesondere eines Gerätes der Unterhaltungselektronik, mit den im Oberbegriff des Anspruches 1 angegebenen Merkmalen.
Ein Hauptanteil der Entwicklungszeiten bei elektronischen Geräten, insbesondere bei Geräten der Unterhaltungselektronik, fällt auf die Erstellung der Bediensoftware. Bei Multimediageräten wird der Anteil der Softwareentwicklung von Bediensoftware an der Gesamtentwicklungszeit und den damit verbundenen Kosten weiter rapide anwachsen.
Aus der US-Patentschrift US 6,466,971 B1 ist ein Verfahren und ein System zum Bedienen und Steuern einer Vielzahl von Geräten über ein Netzwerk bekannt. Bei den Geräten handelt es sich um Haushaltsgeräte, unter anderem um Fernsehgeräte, Videorekorder, Radios oder Satellitenreceiver. In einer Ausführungsform des Verfahrens und des Systems wird ein Client-Gerät an ein Haushaltsnetzwerk angeschlossen, wobei das Client-Gerät in der Lage ist, Benutzerschnittstellendaten darzustellen. Es wird ein erstes Haushaltsgerät an das Haushaltsnetzwerk angeschlossen, wobei das erste Haushaltsgerät Benutzerschnittstellendaten in einem vordefinierten Format speichert und wobei die Benutzerschnittstellendaten eine Benutzerschnittstelle zum Bedienen und Steuern des ersten Client-Gerätes über das Haushaltsnetzwerk definieren. Es wird ein zweites Haushaltsgerät an das Haushaltsnetzwerk angeschlossen, welches Programmschnittstellendaten in strukturierter Form zum im Wesentlichen autonomen Bedienen und Steuern des zweiten Haushaltsgerätes durch ein oder mehrere an das Haushaltsnetzwerk angeschlossene Haushaltsgeräte aufweist. Die Daten können ein XML-Datenformat aufweisen. Das Client- Gerät empfängt Benutzerschnittstellendaten vom ersten Haushaltsgerät über das Haushaltsnetzwerk. Es werden Benutzereingaben als Reaktion eines Benutzers im Dialog mit der Benutzerschnittstelle übernommen. Es werden Steuer- und Bediendaten vom Client-Gerät auf Basis der Benutzereingaben zum ersten Haushaltsgerät gesendet, um einen autonomen Austausch von Programmschnittstellen zwischen dem ersten und zweiten Haushaltsgerät zu veranlassen, um dann den Betrieb aufzunehmen. In einer Ausführungsform kann das Client-Gerät Bedienoberflächen eines Server-Gerätes darstellen, die als Grafikobjektdaten von dem jeweiligen zu bedienenden Server-Gerät über das Netzwerk geladen werden. Die Server-Geräte selbst verfügen über keine Benutzereingabe und über kein Display. Die Grafikobjektdaten der jeweiligen Server-Geräte erlauben eine individuelle Darstellung von Bedienoberflächen der jeweiligen Server-Geräte mit individuellem "look and feel". Es können für die Server-Geräte einheitliche Datenmodelle für die Grafikobjektdaten verwendet werden.
Aus der US-Offenlegungsschrift US 2000/0085020 A1 ist ein System und ein Verfahren zum Erzeugen von Benutzerschnittstellen für Softwareanwendungen bekannt. Das System und Verfahren erlaubt es einem Entwickler, die Entwicklung einer Benutzerschnittstelle von der Entwicklung der Logik der dahinterstehenden Anwendung zu trennen. In einer Ausführungsform ist eine graphische Benutzerschnittstelle für Anwendungen spezifiziert, die ein XML-Dokument als Datei für die Anwendungsschnittstelle verwendet. Bei der Ausführung der Anwendung wird diese Datei geparst, wobei die Spezifikationen in der Datei zum Laden von graphischen Bedienelementen von einer Schnittstellen-Bibliothek verwendet werden, um eine Benutzerschnittstelle zu kreieren. Die graphische Benutzerschnittstellen-Bibliothek kann eine Sammlung von JAVA-Klassen und Schnittstellen sein, die eine graphische Schnittstellendefinitionsdatei, wie z. B. ein XML-Dokument, als Eingabe heranzieht.
Es ist deshalb Aufgabe der Erfindung, ein universell einsetzbares Verfahren für die Generierung von Bedienoberflächen zu entwickeln, das Portabilität, Modularität, Erweiterbarkeit und Wiederverwendbarkeit sicher stellt, wobei objektorientierte Techniken zur Anwendung kommen sollen.
Ein weiteres Ziel der Erfindung ist es, das Verfahren für die Darstellung von Bedienelementen und die Steuerung von Gerätefunktionen miteinander vernetzter Geräte so zu gestalten, dass eine universelle Bedienung auch nachträglich hinzukommender Komponenten auf einfache Weise ermöglicht wird.
Die Aufgabe wird erfindungsgemäß durch ein Verfahren gelöst, wie es im Anspruch 1 angegeben ist.
Die Erfindung gibt ein neues Verfahren für die Erstellung von Bedienoberflächen und damit für die Steuerung von Gerätefunktionen an, das erweiterungsfähig und universell für einzelne Geräte mit Display und auch für Kombinationen eines ersten Gerätes mit Display und weiteren Geräten einsetzbar ist. Dies kann z. B. ein zentrales Steuer- und Überwachungsgerät und eine Vielzahl daran angeschlossener Sub- oder Tochtergeräte sein, die über einen Bus mit dem ersten und/oder untereinander kommunizieren. Damit ein Entwickler nicht mehr eine spezifische Programmiersprache anwenden und sich mit einzelnen Oberflächenelementen und deren Konstruktion auseinandersetzen muss, kommt gemäß der Erfindung eine XML-basierende Auszeichnungssprache für menügesteuerte Oberflächen zur Anwendung, nämlich eine On-Screen-Display Markup Language, kurz OSDML genannt.
Die erstellten OSDML-Dokumente werden dabei innerhalb des Systems an jene Geräte weitergeleitet, die Bedienoberflächen, z. B. das definierte erste Gerät, darstellen können. Diese Geräte besitzen eine sogenannte OSDML-Engine, welche die XML-Strukturen interpretiert und die Bedienoberfläche mit den entsprechenden Komponenten nach dem MVC-Muster konstruiert. Um eine Bedienoberfläche erstellen zu können, müssen die zur Verfügung stehenden graphischen Bedienelemente und deren Datenmodelle in jedem Gerät beschrieben und abgespeichert werden. Die Beschreibungsregeln werden in einer Dokumenttyp-Deklaration (DTD) festgehalten. Grundsätzlich muss ein erstelltes OSDML-Dokument den Regeln der DTD gehorchen. In OSDML-Dokumenten wird ausschließlich nur die Struktur der Bedienoberfläche festgehalten, die Art und Weise, wie sich die einzelnen Oberflächenelemente präsentieren, bleibt dem Entwickler bzw. dem OSD-Designer überlassen.
Die Elemente der Bedienoberfläche erfahren dabei eine konsequente Umsetzung des "Model-View-Controller-Konzeptes" (MVC). Das MVC-Paradigma beschreibt allgemein eine Komponente (Model), ihre Präsentation (View) und ihre Manipulation (Controller). Der entscheidende Vorteil des MVC-Konzep tes in der TV-Welt ist die Unabhängigkeit der Komponente von dem View, also der graphischen Darstellung auf dem Bildschirm. Es ist völlig unerheblich, was sich konkret hinter einer Komponente respektive dem Model verbirgt, beziehungsweise was mit ihr steuerbar ist (z. B. Lautstärke). Wichtig ist nur, dass sie eine definierte Schnittstelle anbietet, über die sich der View Zugriff auf die benötigten Daten verschaffen kann.
Ein weiterer Vorteil ist, dass beliebig viele Views auf dasselbe Model zugreifen können. Somit ist es möglich, die Daten mit mehreren Views auf unterschiedliche Weise darzustellen. Die Entkopplung von View und Model ermöglicht eine kontextabhängige Präsentation ("look-and-feel") der Komponente und des Models auf dem Display, was zu einer enormen Steigerung der Wiederverwendbarkeit getesteter Softwarekomponenten führt.
Um die Komplexität eines solchen Softwaresystems beherrschbar und wartbar halten zu können, ist das System schichtenförmig aufgebaut. Innerhalb dieser Schichtenarchitektur ("layered architecture") sollten die Funktionalitäten der einzelnen Schichten definiert und voneinander abgegrenzt sein. Die Ebenen bieten definierte Dienste an, die prinzipiell nur von den benachbarten Schichten verwendet werden. Damit sich der Entwickler nicht mit plattformspezifischen Besonderheiten auseinandersetzen muss, werden Betriebssystem und Hardware von dem restlichen hardware-unabhängigen System entkoppelt. Eine Entkopplung wird durch Einziehen einer Hardware-Abstraktionsschicht (HAL; Hardware Abstraction Layer) und einer Betriebssystem-Abstraktionsschicht (OSAL; Operating System Abstraction Layer) erreicht. Diese Abstraktionsebenen stellen den darüber liegenden Schichten hardware- und betriebssystem-unabhängige Dienste zur Verfügung und binden die darunter befindliche Hardware-Plattform inklusive Betriebssystem an das System an.
Die Erfindung gibt ein neues softwaregestütztes Bedien- und Darstellungssystem an, das einerseits komplett unabhängig von der aktuellen Verfügbarkeit des Zielsystems erstellt werden kann und andererseits eine schnelle Adaption auf die Ziel-Hardware durch Austausch der Abstraktionsschichten erlaubt. Der Einsatz einer systemunabhängigen Auszeichnungssprache wie OSDML eröffnet neue Möglichkeiten bei der Entwicklung von Bedienoberflächen, unter anderem eine schnelle Entwicklung von Bedienoberflächen mit OSDML-Editoren (WYSIWYG), Robustheit (es ist kein Systemeingriff notwendig) und die Möglichkeit der Vernetzung von Geräten (OSDML-basierende Kommunikation).
Zum besseren Verständnis der Erfindung seien zunächst anhand der 1 allgemeine Begriffe der Auszeichnungssprache erläutert.

• Eine Meta-Auszeichnungssprache ist eine formale Sprache zur Erzeugung (Konstruktion, Definition) von Auszeichnungssprachen.
• Eine Auszeichnungssprache (Markup Language) beschreibt die logischen Elemente eines Dokuments mit Hilfe von Markierungen (Tags). Der Begriff ist deutlich abzugrenzen von dem der Programmiersprache, denn Auszeichnungssprachen fehlen die für Programmiersprachen typischen Konstrukte, wie Schleifen und Verzweigungen, aber auch Variablen, Funktionen.
• SGML (Standard Generalized Markup Language), seit 1986 internationaler Standard, ist die Obermenge aller Meta-Auszeichnungssprachen. SGML legt die Regeln für die Auszeichnung von Textteilen/Elementen in einem Dokument fest; z. B. beginnt eine Auszeichnung (Tag) mit "<" und wird mit dem Zeichen ">" abgeschlossen. Die Bedeutung der Tags ("<name>") wird in Document Type Definitions (DTD) festgelegt.
• XML (eXtensible Markup Language) ist eine Untermenge von SGML (Standard Generalized Markup Language).
• XML ist ein Standard des World-Wide Web Consortiums (W3C), d. h. mit anderen Worten XML gehört keinem Unternehmen.
• XML ist ein plattform-unabhängiges Format.
• Man kann in XML beliebig viele neue Tags und Attribute definieren (DTDs). Somit erlaubt XML eine unbegrenzte Anzahl von Auszeichnungssprachen zu definieren, die auf dem Standard von XML basieren (z. B. XHTML, MathML ...).
• XML-Dokumente sind lesbar (können mit einfachen Texteditoren erstellt werden), lassen sich leicht austauschen (Textformat) und verarbeiten (XML-Parser).
• Bei XML-Dokumenten muss zwischen "well-formed" und "valid" unterschieden werden. Ein XML-Dokument ist "well-formed", wenn es den Auszeichnungsregeln entspricht, und ist valid", wenn es den Regeln der DTD genügt. In einer DTD (Dokumenttyp-Deklaration) werden Syntax, Struktur und Bedeutung der Tags festgelegt.

XML trennt Inhalt (*.xml) und Struktur (*.dtd) von Dokumenten. Die Elemente sind die Grundbausteine, aus denen ein Dokument besteht. Elemente sind hierarchisch ineinander verschachtelt. Ein XML-Element wiederum besteht aus einem Anfangs-Tag und einem Ende-Tag und Daten dazwischen. Der Anfangs- und Ende-Tag beschreibt die Daten zwischen den Tags. Die Daten innerhalb der Tags werden als Wert des Element bezeichnet. Zum Beispiel, ist das XML Element unterhalb ein Menu-Element mit dem Wert "Hauptmenü":
<Menu>Hauptmenü</Menu>
Ein Dokument ist "well-formed", wenn alle XML-Tags korrekt verschachtelt sind, d. h. jeder Tag wird durch den entsprechenden schließenden Tag begleitet. Wohlgeformte XML-Dokumente brauchen jedoch keine DTD zu besitzen. Ein Dokument, das dies aufzeigt, ist nachfolgend dargestellt:
Ein "valid"-Dokument besitzt eine DTD (Struktur), die entweder im XML-Dokument selbst oder in einem externen Dokument beschrieben wird (Verweis im XML-Dokument, Extension *.dtd).
Ein Dokument ist erst dann gültig, wenn es nur erlaubte Elemente (beschrieben in einer DTD) verwendet und diese richtig ineinander verschachtelt sind.
Für das vorherige Beispiel könnte eine Dokumenttyp-Deklaration wie folgt aussehen:
An das Verfahren für die Darstellung von Bedienelementen und die Steuerung von Gerätefunktionen miteinander vernetzter Geräte sind folgende Anforderungen gestellt:

• eine weitgehend plattformunabhängige OSD-Entwicklung
• objekt-orientierter und modularer Aufbau
• niedriger Ressourcenverbrauch
• hohe Portier- und einfache Erweiterbarkeit (Abstraction-Layer, MVC-Modell)
• Beschreibung der Oberfläche in XML (Definition einer OSD-Auszeichnungssprache)
• Vernetzung von Geräten – OSD upload-fähig
• Schaffung eines Standards für die Kommunikation zwischen Geräten

Diese grundsätzlichen Zusammenhänge der Auszeichnungssprache vorausgeschickt, sollen durch die Erfindung eine auf XML basierende Bedienoberfläche für alle Geräte und deren Verbund erzielt werden.
In einem heterogenen System können Geräte nur in einem sehr beschränkten Umfang Informationen austauschen. Jedes Gerät bietet dem Benutzer nur eigene Dienste bzw. Bedienoberflächen an oder arbeitet innerhalb eines eigenen homogenen Teilsystems mit proprietären Lösungen.
Durch Einführung eines einheitlichen Bedienoberflächen-Protokolls nach der Erfindung soll es nun möglich sein, Geräte verschiedener Hersteller von einem Gerät aus bedienen zu können. Hierzu beschreiben die Geräte ihre Oberflächen in einer definierten XML-basierenden Auszeichnungssprache (im weiteren OSDML – On Screen Display Markup Language – genannt), die im Netzwerk anderen Geräten zur Verfügung gestellt werden. Innerhalb dieses Netzwerkes werden zwei Arten von Gerätetypen spezifiziert: zweite Geräte, die ihre Bedienoberfläche zur Verfügung stellen möchten (z. B. VCR), und erste Geräte, die diese darstellen können (z. B. TV). Geräte, die OSDs von fremden Geräten darstellen und/oder mit diesen kommunizieren möchten, müssen sich an die in OSDML definierten Strukturen (DTD) halten. In OSDML wird nur die Struktur festgehalten (z. B. Menü mit drei Menüpunkten), die Art und Weise wie sich das OSD dem Benutzer darstellt, bleibt den gerätespezifischen Ausführungen überlassen. Dem Gerätehersteller wird also kein system-fremdes "Look-and-Feel" aufgezwungen, und der Benutzer muss sich nicht, wie bisher, mit den unterschiedlichen herstellerabhängigen Bedienoberflächen auseinandersetzen.
Für die Interpretation der OSDML-Dokumente ist in dem ersten Gerät eine OSDML-Engine enthalten, die die XML-Strukturen des ersten Gerätes und die des zu steuernden zweiten Gerätes ausliest und repräsentiert. Diese Engine steht für hohe Portierbarkeit, Erweiterbarkeit, niedrigen Ressourcenverbrauch (RAM, ROM) und einen klar strukturierten objekt-orientierten Aufbau der Software, z. B. realisiert in der Programmiersprache C++.
Die hohe Portierbarkeit wird durch eine dünne Schicht von Code (Adaption Layer), die zwischen der OSDML-Engine und der Hardware-Plattform liegt, erreicht. Weiterhin kann durch Adaptierung des internen Layout-Managers eine komplett neue, individuelle Benutzeroberfläche erstellt werden.
Ein schematischer Überblick über das Systemkonzept ist im Blockbild in 2 dargestellt, eine im System enthaltene XML-Engine-Architektur in 3.
Der Stream Manager ist die zentrale Schnittstelle für den Empfang von XML-Dokumenten. Die XML-Strukturen werden an den nachgeschalteten Parser weitergegeben.
Der generische Parser erkennt anhand der standardisierten Anweisungsregeln XML-Inhalte (Elemente, Attribute etc.) und reicht diese an den Interpreter weiter.
Der Interpreter erkennt die strukturellen Beziehungen der einzelnen XML-Inhalte (z. B. View oder Model), setzt diese zu Objekten zusammen und ruft die entsprechenden API-Funktionen (z. B. SliderView oder SliderModel kreieren) des Component Builders auf.
Der Component-Builder stellt die API für die Konstruktion der Bedienelemente nach dem Model/View/Controller-Konzept zur Verfügung.
Die einzelnen Bedienelemente werden gemäß Bedienoberflächenbeschreibung (XML-Dokument) zu Applikationen zusammengesetzt (z. B. TV-Menü, Programmliste etc.) und in einem Dokument abgelegt. Ein Dokument beschreibt die komplette Bedienoberfläche eines Gerätes (Applikationen, Datenmodelle und Texttabellen). Im Document Container werden alle erstellten Bedienoberflächen (z. B. TV, VCR) abgelegt.
Das Model/View/Controller-Konzept ist in 4 dargestellt. Bei der Realisierung der graphischen Bedienoberfläche bzw. deren Komponenten wird zweckmäßigerweise das Model-View-Controller-Entwurfsmuster angewendet. Das MVC-Konzept besteht aus drei Teilen:

• Model (verwaltet Daten)
• View (ist zuständig für die Darstellung der Daten)
• Controller (manipuliert Model und/oder View, z. B. Auswertung von Fernbedienungsdaten)

Die Kommunikation zwischen Model, View und Controller wird nachfolgend kurz skizziert.
Die Views (z. B. ein Schieberegler) registrieren sich beim Model (z. B. Datenobjekt mit value = 20) und werden automatisch bei Veränderungen im Model benachrichtigt (Observer-Pattern). Einer der Vorteile des MVC-Konzeptes ist die Unabhängigkeit des Models vom View. Es ist völlig unerheblich, wie die Daten verwaltet werden oder welche Komplexität sie besitzen. Wichtig ist nur, dass eine definierte Schnittstelle existiert, über die sich ein View Zugriff auf die Daten verschaffen kann. Ein weiterer Vorteil ist, dass die Anzahl der Views, die auf dieselben Daten zugreifen, nicht beschränkt ist (siehe 4: Schieberegler und Drehknopf).
Jeder View bezieht sich auf ein Model, das im OSDML-Dokument abgelegt ist. Anstatt für jedes graphische Bedienelement Funktionen oder API-Codes zu definieren, die bei Änderung des Views aufgerufen werden, werden deren Datenmodelle (Models) im System versendet. Dies hat den Vorteil, dass sich die Engine (3) nicht darum kümmern muss, was sich für eine Funktionalität hinter den einzelnen Bedienelementen verbirgt. Bei der Beschreibung der Oberfläche in OSDML werden Model und deren Views getrennt beschrieben. Die Regeln sind in der Dokumenttyp-Deklaration (OSDML.dtd) für OSDML festgelegt, an die sich der Hersteller halten muss.
OSDML-Beispiel: Slider-Deklaration (Auszug aus der OSDML.dtd):
Hier wird in AttrViewSlider der View und in ModelSlider das Model beschrieben. Alle Slider in dem OSDML-Dokument müssen diesen Regeln gehorchen.
Ein OSDML-Validierungstool überprüft die Korrektheit eines erstellten OSDML-Dokumentes. Ein Dokument ist erst dann gültig, wenn der Inhalt den Auszeichnungs- und Deklarationsregeln genügt, wie aus nachfolgender Darstellung ersichtlich ist.
OSDML-Beispiel: Auszug aus einem OSDML-DokumentEine mögliche Oberflächenbeschreibung könnte z. B. wie folgt aussehen (*.xml):
Wie zu erkennen ist, bezieht sich ein View immer auf ein Model. Wie im Falle der Temperaturregelung können sich auch mehrere Views auf ein und dasselbe Model beziehen; außerdem können auch Geräte, die nicht zur Gruppe Unterhaltungselektronik gehören, z. B. aber über ein Fernsehgerät ansteuerbar sind, ihre Oberfläche zur Verfügung stellen (z. B. Heizungsregelung, Steuerung von Küchengeräten etc.). Bei Änderungen des Models (z. B. temperature wird von 21 auf 22 geändert) werden die entsprechenden Views auf dem ersten Gerät benachrichtigt; außerdem wird das modifizierte Model (value = "22") im System versendet. Das Gerät "Heizungsregelung" wertet die entsprechenden empfangenen Daten des Models aus. Der Nachrichtenaustausch ist bidirektional, d. h. bei Änderungen direkt am Gerät ("Heizungsregelung") wird ebenfalls das modifizierte Model versendet, das dann eine Benachrichtigung der Views zur Folge hat (Views werden abhängig vom Kontext auf dem ersten Gerät neu gezeichnet).
Prinzipiell wird das geänderte Model als Nachricht versendet. Allen Geräten im Netzwerk steht diese Nachricht zur Verfügung. Für die Model-Kommunikation stehen zwei Protokolle zur Auswahl: Das Model wird entweder in XML-Notation (ModelProtocolType = XML) oder als Binärstrom (ModelProtocolType = Binary) versendet.
Nachrichtenformat ModelProtocolType = XML ist wie folgt strukturiert:
{modelType, modelName, attribute 1 ... attribute n}
modelType = ModelMenu, ModelMenultem, ModelSlider, ModelChoiceBar, ModelList, ModelPanel, etc; Struktur beschrieben in der OSDML.dtd
modelName = eindeutiger Name innerhalb der Applikation; vergibt Gerät, welches seine Bedienoberfläche zur Verfügung stellt (z. B. ms_temperature)
attribute n = abhängig von modelType Beispiel Slider "temperature"
Das Nachrichtenformat ModelProtocolType = Binary ist wie folgt strukturiert:
{short modelType, string modelName, attribute 1 ... attribute n}
modelType = 0x0000 .. 0x07ff (ModelMenu = 0x0000, ModelMenuItem = 0x0001, ModelSlider = 0x0002 ...)
modeName = Eine Zeichenkette (nicht nullterminiert) von der Länge x (short)
attribute n = abhängig von modelType Beispiel Slider "temperature"
als zu übertragender Binärstrom:
0x0002,
0x000E, 0x6D, 0x73, 0x5F, 0x74, 0x65, 0x6D, 0x70, 0x65, 0x72, 0x61, 0x74, 0x75, 0x72, 0x65,
0x0015, 0x0012, 0x001B
Beide Nachrichtenformate haben ihre Vorzüge: ModelProtocolType = XML hält sich an die XML-Notation (Auszeichnung + Deklaration), benötigt aber einen einfachen Parser, um Elemente und Inhalt zu bestimmen. Das zweite Format (ModelProtocolType = Binary) hat den Vorteil, dass die Geräte den Binärstrom mit Hilfe von "look-up tables" einfach interpretieren können. Prinzipiell müssen Geräte, die ihre Bedienoberfläche in OSDML beschreiben, mindestens den Protokolltyp "Binary" unterstützen (Registry-Abfrage).
Für die Übermittlung der Dokumente (Beschreibung der Bedienoberfläche) und Nachrichten sind Communication Manager und Messaging System verantwortlich. Sie sorgen dafür, dass Nachrichten ihren Empfänger erreichen bzw. fehlerfrei an die höheren Schichten der Anwendung weitergereicht werden. Die Nachrichten werden prinzipiell mit einem Nachrichtenkopf (Header) versehen, der u. a. den Protokolltyp, die Gerätebezeichnung, eine fortlaufende Nachrichtennummer, die Nachrichtenlänge und eine Prüfsumme enthält.
Der Nachrichtenaustausch ist durch die Adaption-Layer-Technik an keinen bestimmten Übertragungsweg gebunden. Der Datenaustausch kann sowohl über drahtgebundene (z. B. IEEE1394, V.24, LAN, EIB, SCART) als auch drahtlose Systeme (z. B. WLAN, Bluetooth) erfolgen.
Alle Geräte, die Bedienoberflächen darstellen können (OSDML-Engine ist integriert), besitzen eine Registry. Hier werden die angeschlossen Geräte im Netzwerk registriert bzw. verwaltet. Die Registry stellt Dienste zum Abfragen von Geräteinformationen zur Verfügung.
5 illustriert schematisch den Nachrichtenverkehr zwischen einem Gerät, das die Fähigkeit besitzt, Bedienoberflächen darzustellen (Gerät A), und einem Gerät, das seine Bedienoberfläche als OSDML-Applikation zur Verfügung stellt (Gerät B).
Die Darstellung zeigt links das Display eines ersten Gerätes, z. B. eines Fernsehgerätes mit Bild-in-Bild-Darstellung einer durch eine OSD-Schaltung eingeblendeten Bedienoberfläche eines angeschlossenen Subgerätes, das rechts eingezeichnet und beispielsweise ein Videorecorder (VCR-Gerät) ist. Die Kommunikation zwischen den beiden Geräte ist in Form einer Ablauftabelle angegeben, die für die Generierung der Bedienoberfläche notwendig ist.
Mit der OSDML-Engine bzw. dem separaten Layout-Manager sind "Look-and-Feel" frei konfigurierbar. Innerhalb der OSDML-Engine (portiert auf Geräte, die OSDML-notierte Oberflächen darstellen möchten) werden Beschreibung und Präsentation von Bedienelementen strikt getrennt. Somit kann der Benutzer aus einem definierten "Look-and-Feel"-Vorrat (Layout-Manager) die Darstellungsform frei wählen. Außerdem besteht die Möglichkeit für den Gerätehersteller, den Präsentationsvorrat mit eigenen kreierten Bedienelementen (Views) zu erweitern.
Die Attribute, wie Farben, Formate, Zuordnungen, Piktogramme, sollten im ersten Gerät den Views zugeordnet werden.
Im nachfolgenden wird das OSD Rapid Development (WYSIWYG) beschrieben. Um sich die Arbeit beim Erstellen von OSDML-basierenden Oberflächen zu erleichtern, kann ein OSDML-Editor verwendet werden, der auf der bisher beschriebenen Komponententechnologie (Component Builder) beruht. Per Drag-and-Drop können Bedienoberflächen und deren zugehörigen Datenmodelle erstellt werden. Die Bedienoberflächen werden in OSDML-Notation gespeichert. Mit Hilfe eines Simulation Tools innerhalb der Entwicklungsumgebung kann das Laufzeitverhalten visualisiert und untersucht werden. Weiterhin besteht die Möglichkeit, auf das "Look-and-Feel" Einfluss zu nehmen (Layout Manager oder OSDML-Beschreibung).
Seinen Erfolg verdankt XML nicht nur seiner Standardisierung durch das World-Wide Web Consortiums (W3C), sondern ebenso einer Reihe von Spezifikationen, die in der Verantwortung des W3C zu Co-Standards gereift sind. Zu einer der interessantesten Spezifikationen gehört XSL, die eine Sprache zur Transformation von XML-Dokumenten in XML-Dokumente mit anderer Struktur (z. B. andere Auszeichnungssprache) oder in Dokumente mit anderem Vokabular (z. B. Programmiersprache) ist. Diese Sprache macht sich die erfindungsgemäß vorgesehene OSDML-Transformation zu nutze. So ist es beispielsweise möglich, eine in OSDML beschriebene Oberfläche in ein Web-Format zu transformieren und diese mit einem Browser adäquat zu repräsentieren. XSLT ist selbst eine XML-gerechte Sprache und besteht aus bestimmten Elementen und Attributen.
Bei der Software-Realisierung sollte bei weiterer Ausgestaltung des Verfahrens berücksichtigt werden, dass die XML-Dokumente unkomprimiert im Textformat gesendet werden. Um eine Verringerung der Bandbreite (z. B. Übertragung über EIB oder serielle Schnittstelle) zu erreichen, wäre eine Komprimierung (Senderseite) und Dekomprimierung (Empfängerseite) mit einfachen standardisierten Algorithmen ratsam.
Auch sollten komprimierte Daten nur in einem heterogenen Netzwerk versendet werden, wenn alle beteiligten Geräte eine Komprimierung akzeptieren (Registry-Abfrage). Um einen universellen Einsatz des Systems zu ermöglichen, sollten die Geräte, die Bedienoberflächen darstellen, prinzipiell die beiden Übertragungsprotokolle "Binary" und "XML" unterstützen. Der nachfolgende Teil beschreibt die Bedienoberfläche des beispielhaften Videorecorders in OSDML.
In OSDML wird nur die Struktur festgehalten (z. B. VCR-Menü mit fünf Menüpunkten), die Art und Weise wie sich die Bedienoberfläche dem Benutzer präsentiert, bleibt den Geräteherstellern überlassen.
Das Ergebnis dieser Programmierung ist in den 6 und 7 dargestellt. Die OSD-Darstellung der VCR-Menüs erfolgt auf dem Display des ersten Gerätes. Zwischen den verschiedenen Funktionen kann mittels einer Cursorbewegung und Betätigung der OK-Funktion ausgewählt werden. Für die Bedienung erscheint das "Video Control"-Feld (7). Die darin angegebenen Steuerfunktionen werden mit dem Cursor ausgewählt und angesteuert. Die Cursorbewegung erfolgt mittels der in 4 dargestellten Fernbedienung, die Cursortasten aufweist. Das Abbild ist in der OSD-Darstellung gezeigt, so dass der Benutzer die jeweilige Betätigung angezeigt erhält.

Claims

Verfahren zum Darstellen mindestens einer Bedienoberfläche auf einem Display eines ersten elektronischen Gerätes und zum Bedienen mindestens eines zweiten elektronischen Gerätes anhand der Bedienoberfläche, die unter Verwendung eines Mikroprozessors und einer OSD-Anzeigeschaltung generiert wird, wobei die Geräte an einen drahtgebundenen oder drahtlosen Bus angeschlossen sind, wobei die Geräte insbesondere Geräte der Unterhaltungselektronik sind und wobei eine einheitliche XML-basierende Auszeichnungssprache für die Bedienoberflächen aller miteinander kommunizierenden ersten und zweiten Geräte verwendet wird, gekennzeichnet durch – Entkopplung der grafischen Darstellung (View) von einem Datenmodell (Model) im steuerbaren Teil des ersten Gerätes mindestens zur kontextabhängigen Präsentation von graphischen Bedienelementen auf dem Display; – Errichtung einer Oberflächenbibliothek in einem Speicher im ersten Gerät durch Zuführen der graphischen Darstellungen (Views) und Datenmodelle (Models) sowie Erstellen von deren Verknüpfungen mittels Mikrocomputer, wobei die graphischen Darstellungen (Views) den graphischen Aufbau der Bedienelemente und deren Platzierung auf der Bedienoberfläche im ersten Gerätes festlegen und dort gespeichert sind und wobei die Datenmodelle (Models) vom dem zumindest einen zweiten Gerät geladen werden, – Darstellung der Verknüpfung über die OSD-Schaltung auf dem Display des ersten Gerätes; – Wunschgemäßes Ändern der Daten der ausgewählten graphischen Darstellungen (Views) mittels einer Orts- und/oder einer fernbedienung am ersten oder zweiten Gerät und – Verändern der Daten des Datenmodells (Models) im zweiten Gerät bzw. im steuerbaren Teil des ersten Gerätes und Speichern in Speichern des ersten und des zweiten Gerätes.
Verfahren nach Anspruch 1, gekennzeichnet durch die Verwendung eines an sich bekannten Model-View-Controller-Konzeptes (MVC) zur Erstellung der Oberflächenbibliothek.
Verfahren nach Anspruch 1, dadurch gekennzeichnet, dass die zur Verfügung stehenden graphischen Bedienelemente und deren Datenmodelle in jedem Gerät beschrieben und abgespeichert werden.
Verfahren nach Anspruch 1 und 3, dadurch gekennzeichnet, dass die einzelnen Views und/oder Models durch eine On-Screen-Display Markup Language (OSDML) beschrieben werden und dass die erstellten OSDML-Dokumente innerhalb des Systems an die in dem ersten Gerät enthaltene OSDML-Engine geleitet werden, welche die XML-Strukturen der Dokumente interpretiert und die Bedienoberfläche mit den entsprechenden Komponenten nach einem Model-View-Controller-Konzept (MVC-Muster) konstruiert, wobei die zur Verfügung stehenden Bedienelemente und deren Datenmodelle beschrieben und einer Dokument-Deklaration (DTD) festgehalten sind und die OSDML-Dokumente ausschließlich die Struktur festhalten, während die einzelnen darzustellenden Komponenten der Bedienoberfläche für die Präsentation definiert abgespeichert sind.
Verfahren nach Anspruch 4, dadurch gekennzeichnet, dass die OSDML-Engine eine durch einen Mikroprozessor realisierte XML-Engine mit folgenden Merkmalen enthält: a) einen Stream Manager als zentrale Schnittstelle für den Empfang von XML-Dokumenten, b) einen nachgeordneten generischen Parser zum Erkennen der XML-Inhalte, wie Elemente, Attribute, mittels standardisierter Anweisungsregeln, c) einen nachgeordneten Interpreter zum Erkennen der strukturellen Beziehungen der einzelnen XML-Inhalte (z. B. View oder Model) und zum Zusammenfügen dieser zu Objekten anhand von API-Funktionen in einem Component Builder, d) einen Document Container, in welchem die XML-Dokumente zu Applikationen zusammen als Dokumente abgelegt werden, die die komplette Bedienoberfläche eines Gerätes beschreiben.
Verfahren nach Anspruch 1, dadurch gekennzeichnet, dass das auf dem Display dargestellte Model und/oder View durch empfangene Fernsteuersignale von einem Fernbedienungsgeber über den Mikroprozessor der OSD-Schaltung manipulierbar ist.
Verfahren nach Anspruch 6, dadurch gekennzeichnet, dass die Views symbolhaft dargestellte Schieberegler und/oder Drehsteller enthalten, deren Einstellwerte mittels Reihen von graphischen Symbolen oder alphanumerisch angezeigt werden.
Verfahren nach einem der vorhergehenden Ansprüche, dadurch gekennzeichnet, dass jede zwischen den Geräten ausgetauschte Nachricht mit einem Header versehen ist, der mindestens Daten über Protokolltyp, Gerätebezeichnung, fortlaufende Nachrichtennummer, Nachrichtenlänge und Prüfsumme enthält.
Verfahren nach einem der vorhergehenden Ansprüche, dadurch gekennzeichnet, dass jedes Gerät, das eine Bedienoberfläche darstellen kann, eine Eintragungsverwaltung (Registry) aller angeschlossenen Geräte durchführt.
Verfahren nach Anspruch 8 oder 9, dadurch gekennzeichnet, dass die Geräte den Protokolltyp "Binary" unterstützen.
Verfahren nach einem der vorhergehenden Ansprüche, dadurch gekennzeichnet, dass eine in OSDML beschriebene Oberfläche nach der XSLT-Spezifikation durch ein Programm vom Mikrocomputer des Gerätes in ein XML-Dokument mit anderer gewünschter Struktur transformiert wird.
Verfahren nach einem der vorhergehenden Ansprüche, dadurch gekennzeichnet, dass die Daten der XML-Dokumente unkomprimiert oder komprimiert übertragen und im Falle der Komprimierung im empfangenden Gerät dekomprimiert werden, wobei die Übertragung in einem heterogenen Netzwerk erfolgt.
Verfahren nach Anspruch 1, dadurch gekennzeichnet, dass in einem Netzwerk ein oder mehrere erste Gerät enthalten sind.