DE60037795T2

DE60037795T2 - Audiovisuelle architektur

Info

Publication number: DE60037795T2
Application number: DE60037795T
Authority: DE
Inventors: Richard Seattle HASHA
Original assignee: GATES III; Gates III William H Medina
Current assignee: GATES III; Gates III William H Medina
Priority date: 1999-02-03
Filing date: 2000-02-03
Publication date: 2009-01-22
Anticipated expiration: 2020-02-04
Also published as: WO2000046660A9; AU3357000A; ATE358846T1; DE60040061D1; WO2000046673A1; CA2396118A1; DE60034218T2; EP1157333A1; WO2000046671A1; WO2000046960A1; WO2000046673A9; DE60035677T2; EP1171819B1; CA2396124A1; WO2000046670A9; CA2396099A1; CA2396131A1; CA2396128A1; AU3591400A; DE60034218D1

Description

Die beschriebene Technologie bezieht sich auf audiovisuelle Systeme.
Eine große Umgebung wie zum Beispiel ein großes Gebäude oder ein großes Haus kann über zahlreiche Audio-/Video-Vorrichtungen verfügen, die sich überall in der Umgebung befinden. Diese AV-Vorrichtungen können CD-Spieler, Lautsprechersysteme, Computersysteme, Fernsehgeräte, Satellitenempfänger, Anzeigen usw. umfassen. Darüber hinaus können zahlreiche Medienquellen verfügbar sein. Ein solches Medium ist eine Jukebox (ein Musikautomat), die eine Vielzahl von Compact Discs enthält. Die AV-Vorrichtungen stellen üblicherweise ein Bedienfeld bereit, über das die Vorrichtung bedient werden kann. Ein CD-Spieler stellt zum Beispiel ein Bedienfeld bereit, das ermöglicht, eine CD zu starten, zu unterbrechen oder zu beenden. Üblicherweise sind die Verbindungen zwischen den AV-Vorrichtungen untereinander statisch. Das heißt, wenn die AV-Vorrichtungen eingerichtet werden, wird Verkabelung zwischen den Vorrichtungen verlegt. Es kann zum Beispiel ein Lautsprecherkabel zwischen einem Verstärker und Lautsprechern verlegt werden.
Eine Schwierigkeit bei solchen statischen Verbindungen untereinander besteht darin, dass es sehr teuer und schwierig ist, alle gewünschten Verbindungen untereinander bereitzustellen und die Verbindungen zu ändern. Eine weitere Schwierigkeit besteht darin, dass es mühsam ist, die Vorrichtungen nur über die Bedienfelder zu bedienen. Es wäre wünschenswert, über eine Architektur zu verfügen, die die dynamische Verbindung zwischen den Vorrichtungen untereinander unterstützen würde.
Friesen J. A., Yang C. L, CLINE R. E. JR.: „Dave: A Plug-and Play Model for Distributed Multimedia Application Development" IEEE Parallel and Distributed Technology: Systems and Applications, 1995, Seiten 22–28–28, legt eine verteilte Audio-Video-Umgebung für das Entwickeln von Anwendungen offen. DAVE stellt eine Programmierschnittstelle für verteilte Plug-and-Plag-Anwendungen (plug-and-plag – sofort betriebsbereit) bereit, ist objektorientiert, bietet die Erweiterbarkeit um weitere Vorrichtungen und Medien, setzt herkömmliche Unix-Netzwerkeinrichtungen für die Übertragung ein und verwendet vorhandene Audio- und Videohardware, die im Allgemeinen auf zahlreichen Workstations zu finden ist. Anwendungsentwickler können Medienvorrichtungen (wie zum Beispiel Kameras oder Mikrofone) als verteilte Ressourcen behandeln, fast genauso wie Workstations Grafiken und Fenster behandeln. Durch Vererbung und Datenunabhängigkeit können Entwickler zusätzliche Vorrichtungen und Medientypen definieren und sie in die Umgebung einbinden. Dieses Plug-and-Plag-Verfahren ermöglicht ein dynamisches Auswechseln von Anwendungen während der Laufzeit.
Sony, Philips, Hitachi, Sharp, Matsushita, Thomson, Toshiba, Grundig: „The HAVI Specification. Specification of the Home Audio/Video Interoperability (HAVI) Architecture. Version 1.0 Beta." HAVI Organization, San Ramon, Kalifornien, USA, 19. November 1998, beschreibt die Heim-Audio-Video-Interoperabilitätsarchitektur (HAVI – home audio/vdeo interoperability), die einen Satz an Services bereitstellt, der die Interoperabilität und die Entwicklung von verteilten Anwendungen in Heimnetzwerken erleichtert. Die HAVI-Architektur umfasst einen Satz Softwareelemente, der erforderlich ist, um die Interoperabilität zu erzielen, einschließlich eines Ereignismanagers (eines Eventmanagers), der einen Ereigniszusteilservice bereitstellt. Die Zustellung eines Ereignisses, das eine Zustandsänderung eines Softwareelements oder des Heimnetzwerks darstellt, erfolgt entweder lokal innerhalb einer einzelnen Vorrichtung oder global an allen Vorrichtungen in dem Netzwerk.
US-A-6.621.662 legt ein Haustechniksystem offen, das eine Anzahl von Teilsystemen zum Steuern verschiedener Aspekte eines Hauses umfasst wie zum Beispiel ein Sicherheitsteilsystem, ein HLK-Teilsystem, ein Beleuchtungssteuerungs-Teilsystem und ein Unterhaltungsteilsystem. Das Netzwerk umfasst einen Hostrechner, der durch eine Hostschnittstelle mit einer Vielzahl von Knoten verbunden ist. Jedes Hardware-Gerät verfügt über ein spiegelbildliches Softwareobjekt in dem Hostrechner, an den Nachrichten gerichtet werden. Die Benutzerschnittstellen für die verschiedenen Teilsysteme teilen ein gemeinsames Schnittstellenverfahren.
EP-A-0.854.607 legt ein Verfahren zum Konfigurieren von Kommunikationsnetzwerken offen, wobei Netzwerkkomponenten über Schnittstellen konfiguriert werden können.
Ansell J., Ozdamer M.: „An Architecture for the Design of TWIN Applications" Proceedings of the International Conference an Communications (ICC), USA, New York, IEEE, 1993, Seiten 1635–1639, legt eine Architektur für die Erzeugung von Anwendungen für das TMN (Telecommunications Management Network – Telekommunikationsverwaltungsnetz) offen. Es beginnt bei dem Konzept von modellbasierter Verwaltung, beschrieben in dem RACE-Projekt – ADVANCE, das empfiehlt, dass ein Netzwerk durch Manipu lieren eines Modells dieses Netzwerks verwaltet werden sollte. Die Anwendungsarchitektur wird im Hinblick auf Informationsmodelle beschrieben. Ein Informationsmodell ist ein Satz von zueinander in Beziehung stehenden Objektklassen-Definitionen, die die Schnittstellen zu den Komponenten in der Anwendungsarchitektur definieren.
AUER S., Hasler J., RUOPP G.: „Das Informationsmodell: Ein Konzept für das Management Offener Kommunikationssysteme" Frequenz, DE, Schiele und Schon GMBH, Berlin, DE, Bd. 47, Nr. 1/2. Januar 1993, Seiten 49 bis 57, legt ein Informationsmodell als ein Konzept für das Verwalten von offenen Kommunikationssystemen offen.
Schapaler G., Kehl W., Azarmi N.: „Model Based Maintenance for MALAS" Electrical Communication, Paris, FR, Juli 1993, Seiten 268 bis 277, legt eine modellbasierte Wartung für MANs (Metropolitan Area Networks – Stadtbereichsnetze) offen.
WO-97/31.451-A legt ein System und ein Verfahren zum Verwalten eines Telekommunikationsnetzes offen. Das System und das Verfahren verwenden eine Netzwerkverwaltungsarchitektur, die eine Überlagerung bereitstellt, in der Netzwerkverwaltungsfunktionen ausgeführt werden.
Es ist das Ziel der vorliegenden Erfindung, ein verbessertes audiovisuelles System und ein entsprechendes Verfahren zum Einrichten eines Weges zwischen einer Quellenkomponente und einer Eingangskomponente in das audiovisuelle System bereitzustellen.
Dieses Ziel wird durch den Inhalt der Hauptansprüche 1 und 22 erreicht.
Bevorzugte Ausführungsformen werden in den Unteransprüchen definiert.
1 ist ein Blockschaltbild, das Vermittlungsschichtobjekte darstellt, die den Weg zwischen Ausgangskomponenten, Schaltmechanismen und Eingangskomponenten abbilden.
2 ist ein Blockschaltbild, das Kommunikations-Steuerungsschicht-Objekte erläutert, die virtuelle Schaltungen darstellen.
3 stellt ein Blockschaltbild dar, das Verwaltungsschichtobjekte erläutert.
4 ist ein Diagramm, das die Einrichtung eines Weges zwischen einer Ausgangskomponente und einer Eingangskomponente erläutert.
5 ist ein Ablaufdiagramm, das eine Funktion eines vollständigen Quellenanschluss-Objekts zum Erstellen eines virtuellen Schaltungsobjekts darstellt.
6 ist ein Ablaufdiagramm einer Beispielimplementierung der Konstruktionseinrichtung für ein virtuelles Schaltungsobjekt.
7 ist ein Ablaufdiagramm, das eine Beispielimplementierung einer Funktion zur Verarbeitung einer nicht-direkten Verbindung erläutert.
10 ist ein Blockschaltbild, das die Komponenten eines Unterhaltungszentrums (entertainment center) erläutert.
11 stellt ein Blockschaltbild dar, das verschiedene Komponenten des AV-Systems erläutert.
12 ist ein Ablaufdiagramm, das das Zuweisen eines Programms zu einem Unterhaltungszentrum erläutert.
13 ist ein Ablaufdiagramm einer Funktion zum Auswählen eines Programms.
14 ist ein Ablaufdiagramm, das eine Beispielimplementierung einer eingestellten aktuellen Programmfunktion eines Unterhaltungszentrumsobjektes darstellt.
15 ist ein Ablaufdiagramm einer Beispielimplementierung einer Funktion zum Holen eines geladenen Player-/Recorder-Objekts.
16 ist ein Ablaufdiagramm einer Beispielimplementierung der Selbstladefunktion des Player-/Recorder-Objekts.
17 ist ein Ablaufdiagramm einer Beispielimplementierung der Programmladefunktion eines Player-/Recorder-Objekts.
18 ist ein Ablaufdiagramm einer beispielhaften Programmladefunktion eines Medienmanager-Objekts.
19 ist ein Ablaufdiagramm einer weiteren beispielhaften Programmladefunktion des Medienmanager-Objekts.
Jede Ausgangskomponente (z. B. ein Laserdisc-Player oder eine Ausgangssoftwarekomponente) verfügt über einen Quellenanschluss, der mit jedem Typ des Ausgangssignals verknüpft ist, den er ausgeben kann. Zum Beispiel kann eine Ausgangskomponente ein Videosignal im RGB-Format durch einen Quellenanschluss ausgeben und ein Audiosignal im AES-Format durch einen anderen Quellenanschluss ausgeben. Jede Eingangskomponente (z. B. eine Lautsprechersystem- oder eine Eingangssoftwarekomponente) verfügt über einen Senkenanschluss, der mit jedem Typ des Eingangssignals verknüpft ist, den er eingeben kann. Zum Beispiel kann eine Eingangskomponente ein Signal im RGB-Format durch einen Senkenanschluss eingeben. Das AV-System bildet jeden Anschluss mit einem entsprechenden Anschluss-Objekt ab. Das AV-System verfügt über ein entsprechendes Primitiv-Quellenanschluss-Objekt für jeden Quellenanschluss und über ein entsprechendes Primitiv-Senkenanschluss-Objekt für jeden Senkenanschluss.
Jeder Quellenanschluss kann mit einem oder mehreren Eingangsanschlüssen verbunden werden. Zum Beispiel kann ein Quellenanschluss, der ein Videosignal ausgibt, mit den Eingangsanschlüssen verschiedener Bildschirmvorrichtungen verbunden sein. Der Weg zwischen einem Quellenanschluss und einem Senkenanschluss kann statisch oder dynamisch sein. Ein statischer Weg kann einer direkten Verbindung zwischen einem Quellenanschluss und einem Senkenanschluss der Ausgangskomponente entsprechen. Ein dynamischer Weg kann durch einen Schaltmechanismus eingerichtet werden. Ein Schaltmechanismus ermöglicht, dass seine Senkenanschlüsse mit seinen Quellenanschlüssen verbunden werden, so dass ein Weg eingerichtet werden kann. Die Verbindung kann eine virtuelle Schaltung oder ein Transportmedium sein. Zum Beispiel kann eine bestimmte Bandbreite des Transportmediums der Verbindung zugewiesen werden. Der Weg zwischen einem Quellenanschluss und einem Senkenanschluss wird als eine Primitivschaltung bezeichnet. Eine Primitivschaltung kann ein direkter Weg zwischen einem Quellenanschluss einer Ausgangskomponente und einem Senkenanschluss einer Eingangskomponente sein. Eine Primitivschaltung kann darüber hinaus ein Weg zwischen einem Quellenanschluss einer Ausgangskomponente und einem Eingangs-Schaltanschluss (einer Bauform des Senkenanschlusses) eines Schaltmechanismus sein. In ähnlicher Weise kann eine Primitivschaltung ein Weg zwischen einem Ausgangs-Schaltanschluss (einer Bauform des Quellenanschlusses) eines Schaltmecha nismus und einem Senkenanschluss einer Eingangskomponente sein. Das AV-System verfügt über ein entsprechendes Primitivschaltungs-Objekt für jeden Weg, wobei ein Signal von einem Quellenanschluss ausgeht und/oder an einen Senkenanschluss endet, über ein entsprechendes Eingangs-Schaltanschlussobjekt für jeden Eingangs-Schaltanschluss und über ein Ausgangs-Schaltanschlussobjekt für jeden Ausgangsanschluss.
1 ist ein Blockschaltbild, das Vermittlungsschichtobjekte darstellt, die den Weg zwischen Ausgangskomponenten, Schaltmechanismen und Eingangskomponenten abbilden. In diesem Beispiel ist ein Laserdisc-Player an ein Lautsprechersystem und eine Anzeige angeschlossen. Der Laserdisc-Player umfasst drei physikalische Quellenanschlüsse: einen für digitales Video, einen für Audio links und einen für Audio rechts. Die Quellenanschlüsse verfügen über einen direkten Weg zu den Eingangs-Schaltanschlüssen des Schaltmechanismus. Das Lautsprechersystem weist zwei Senkenanschlüsse auf: einen für Audio links und einen für Audio rechts. Die Anzeige weist einen Senkenanschluss für digitales Video auf. Die Senkenanschlüsse der Ausgabegeräte verfügen über direkte Wege zu den Ausgangs-Schaltanschlüssen des Schaltmechanismus. Das AV-System stellt jede dieser Komponenten mit einem entsprechenden Objekt im Speicher dar. Das Player-Recorder-Objekt 101 entspricht dem Laserdisc-Player. Das Lautsprechersystem-Objekt 102 entspricht dem Lautsprechersystem, und das Anzeige-Objekt 103 entspricht der Anzeige. Das AV-System stellt mehrere Anschlüsse einer Komponente durch ein einzelnes Gesamtanschluss-Objekt dar. Das Quellenanschluss-Objekt 104 entspricht den Quellenanschlüssen des Laserdisc-Players, das Senkenanschluss-Objekt 105 entspricht den Senkenanschlüssen des Lautsprechersystems, und das Senkenanschluss-Objekt 106 entspricht dem Senkenanschluss der Anzeige. Jedes Anschluss-Objekt kann verschachtelte Anschluss-Objekte enthalten, um die Anschlüsse einer Komponente in eine Hierarchie zu gliedern. In diesem Beispiel werden die Quellenanschlüsse des Laserdisc-Players durch ein Gesamt-Quellenanschluss-Objekt 104 dargestellt, das zwei Kind-Quellenanschluss-Objekte enthält. Das eine Kind-Quellenanschluss-Objekt 107 stellt die Audio-Quellenanschlüsse dar, und das andere Kind-Quellenanschluss-Objekt 108 stellt den Video-Quellenanschluss dar. Das Quellenanschluss-Objekt, das den Audio-Quellenanschluss darstellt, enthält zwei Quellenanschluss-Objekte. Ein Quellenobjekt 109 stellt den linken Audio-Quellenanschluss dar, und das andere Quellenanschluss-Objekt 110 stellt den rechten Audio-Quellenanschluss dar. In ähnlicher Weise stellt das Senkenanschluss-Objekt 105 die Senkenanschlüsse des Lautsprechersystems dar und enthält zwei Kind- Senkenanschlüsse. Das eine Senkenanschluss-Objekt 111 stellt den linken Audio-Senkenanschluss dar, und das andere Kind-Senkenanschluss-Objekt 112 stellt den rechten Audio-Senkenanschluss dar. Da die Anzeige nur über einen Senkenanschluss verfügt, weist ihr entsprechendes Senkenanschluss-Objekt 106 keine Kind-Senkenanschlüsse auf. Ein Quellenanschluss-Objekt oder ein Senkenanschluss-Objekt, das keinen Kindanschluss aufweist, wird als ein Primitivanschluss-Objekt bezeichnet. Die Quellenanschluss-Objekte 109 und 110 sind zum Beispiel Primitiv-Quellenanschlüsse. Ein Anschluss-Objekt, das kein Kind eines anderen Anschluss-Objekts ist, wird als ein vollständiges Anschluss-Objekt bezeichnet. Das Quellenanschluss-Objekt 104 ist zum Beispiel ein vollständiges Quellenanschluss-Objekt. Das Senkenanschluss-Objekt 106 ist sowohl ein Primitiv-Senkenanschluss-Objekt als auch ein vollständiges Senkenanschluss-Objekt.
Das AV-System kann jeden Weg durch ein Primitivschaltungs-Objekt darstellen. In diesem Beispiel entspricht das Primitivschaltungs-Objekt 113 einem direkten Weg zwischen dem linken Audio-Quellenanschluss des Laserdisc-Players und einem Eingangs-Schaltanschluss des Schaltmechanismus. Das AV-System stellt den Schaltmechanismus durch ein Schaltobjekt 114 dar. Ein Schaltobjekt umfasst ein Eingangs-Quellenanschluss-Objekt 115 für jeden seiner Eingangs-Schaltanschlüsse und ein Ausgangs-Schaltanschluss-Objekt 116 für jeden seiner Ausgangs-Schaltanschlüsse.
Das AV-System stellt einen Weg für ein Signal zwischen einem vollständigen Quellenanschluss und einem vollständigen Senkenanschluss durch eine virtuelle Schaltung dar. Ein Signal bildet einen tatsächlichen Informationskontext ab, der sich auf einem Weg befindet. Eine virtuelle Schaltung kann statische und dynamische Verbindungen darstellen. 2 ist ein Blockschaltbild, das Kommunikations-Steuerungsschicht-Objekte erläutert, die virtuelle Schaltungen darstellen. Das AV-System stellt eine virtuelle Schaltung durch ein virtuelles Schaltungsobjekt dar. Das virtuelle Schaltungsobjekt 201 entspricht dem Weg zwischen dem vollständigen Quellenanschluss des Laserdisc-Players und dem vollständigen Senkenanschluss des Lautsprechersystems. Das virtuelle Schaltungsobjekt 202 entspricht dem Weg zwischen dem Quellenanschluss des Laserdisc-Players und dem vollständigen Senkenanschluss der Anzeige. Das virtuelle Schaltungsobjekt 201 entspricht nur den Audio-Quellenanschlüssen des Laserdisc-Players, und das virtuelle Schaltungsobjekt 202 entspricht nur den Video-Quellenanschlüssen des Laserdisc-Players. Jedes virtuelle Schaltungsobjekt enthält Primitiv-Bindungs-Informationen entsprechend jedem der Pfade innerhalb der virtuellen Schaltung. Zum Beispiel enthält das virtuelle Schaltungsobjekt 201 Primitiv-Bindungs-Informationen 203 und 204. Das AV-System ermöglicht es, dass jeder Quellenanschluss an mehrere Senkenanschlüsse angeschlossen werden kann.
3 stellt ein Blockschaltbild dar, das Verwaltungsschichtobjekte erläutert. Das AV-System stellt die Signale dar, die durch die Quellenanschlüsse einer Ausgangskomponente als Stream ausgegeben werden. Das heißt, jeder Ausgang gibt einen Stream von Signalen aus. Die Signale innerhalb des Streams sind hierarchisch in einer Weise gegliedert, die der Weise ähnlich ist, in der Quellenanschlüsse innerhalb eines vollständigen Quellenanschlusses gegliedert sind. Das AV-System stellt den Stream einer Ausgangskomponente durch ein Stream-Objekt dar, das andere Stream-Objekte enthalten kann. In diesem Beispiel werden die Ausgangssignale des Laserdisc-Players durch das Stream-Objekt 301 dargestellt. Die Audiosignale des Laserdisc-Players werden durch das Kind-Stream-Objekt 302 dargestellt, und das Videosignal des Laserdisc-Players wird durch das Kind-Stream-Objekt 303 dargestellt. Das Audio-Stream-Objekt enthält ein Kind-Stream-Objekt 304, das das linke Audiosignal darstellt, und ein Kind-Stream-Objekt 305, das das rechte Audiosignal darstellt. Ein Stream-Objekt, das keine anderen Stream-Objekte enthält, wird als Primitiv-Stream-Objekt bezeichnet. Ein Stream-Objekt, das nicht in anderen Stream-Objekten enthalten ist, wird als vollständiges Stream-Objekt bezeichnet. Das Stream-Objekt 301 ist zum Beispiel ein vollständiges Stream-Objekt, und das Stream-Objekt 304 ist ein Primitiv-Stream-Objekt. Jedes Primitiv-Stream-Objekt enthält ein Signal-Objekt, das dem Signal entspricht, das durch den entsprechenden Quellenanschluss ausgegeben wird. Das Signal-Objekt 306 entspricht dem Signal, das zwischen dem linken Audio-Quellenanschluss des Laserdisc-Players und dem linken Senkenanschluss des Lautsprechersystems gesendet wird. Das Signal-Objekt 307 entspricht dem Signal, das zwischen dem rechten Audio-Quellenanschluss des Laserdisc-Players und dem rechten Senkenanschluss des Lautsprechersystems gesendet wird. Das Signal-Objekt 308 entspricht dem Signal, das von dem Video-Quellenanschluss des Laserdisc-Players zu dem Senkenanschluss der Anzeige gesendet wird.
4 ist ein Diagramm, das die Einrichtung eines Weges zwischen einer Ausgangskomponente und einer Eingangskomponente erläutert. Es wird ein Weg unter Verwendung eines Objekts, das die Ausgangs-Komponente darstellt, und eines Objekts, das die Eingangs-Komponente darstellt, eingerichtet. In Schritt 401 fordert der Prozess das Ausgangs-Objekt auf, einen Zeiger auf ein vollständiges Quellenanschluss-Objekt bereitzustellen. In Schritt 402 fordert der Prozess das Quellenanschluss-Objekt auf, einen Zeiger auf sein vollständiges Stream-Objekt bereitzustellen. In Schritt 403 fordert der Prozess das Eingangs-Objekt auf, einen Zeiger auf sein vollständiges Senkenanschluss-Objekt bereitzustellen. In Schritt 404 fordert der Prozess das Quellenanschluss-Objekt auf, ein virtuelles Schaltungsobjekt zu erzeugen, das einen Weg zwischen dem Quellenanschluss und dem Senkenanschluss einrichtet. Daraufhin ist der Prozess abgeschlossen.
5 ist ein Ablaufdiagramm, das eine Funktion eines vollständigen Quellenanschluss-Objekts zum Erstellen eines virtuellen Schaltungsobjekts darstellt. Diese Funktion führt die Verarbeitung aus, die zum Einrichten eines Weges für ein Signal zwischen einem Primitiv-Quellenanschluss und einem Primitiv-Senkenanschluss erforderlich ist. Der Funktion zum Erzeugen einer virtuellen Schaltung wird ein Zeiger auf das Senkenanschluss-Objekt zugeleitet. In Schritt 501 erzeugt die Funktion ein neues virtuelles Schaltungsobjekt, wobei ein Zeiger auf das Quellenanschluss-Objekt und einen Zeiger auf das Senkenanschluss-Objekt weitergegeben wird. In Schritt 502 fügt die Funktion das virtuelle Schaltungsobjekt zu einer Liste von virtuellen Schaltungen für das Quellenanschluss-Objekt hinzu. Daraufhin kehrt die Funktion zurück.
6 ist ein Ablaufdiagramm einer Beispielimplementierung der Konstruktionseinrichtung für ein virtuelles Schaltungsobjekt. Der Konstruktionseinrichtung wird ein Zeiger auf ein Quellenanschluss-Objekt und ein Zeiger auf ein Senkenanschluss-Objekt zugeleitet. In Schritt 601 ruft die Konstruktionseinrichtung einen Zeiger auf den mit dem Quellenanschluss-Objekt verknüpften Stream ab. In Schritt 602 weist die Konstruktionseinrichtung dem Senkenanschluss-Objekt den Stream durch Aufrufen der Streamzuweisungs-Funktion des Senkenanschluss-Objekts zu, wobei ein Zeiger auf das Stream-Objekt weitergegeben wird. Die Streamzuweisungs-Funktion gibt die Zahl der dem vollständigen Senkenanschluss-Objekt zugewiesenen Signal-Objekte innerhalb des Stream-Objekts zurück. In den Schritten 603–610 führt die Konstruktionseinrichtung eine Schleife aus und erzeugt ein Primitiv-Bindungs-Objekt für jedes Signal-Objekt, das dem Senkenanschluss-Objekt zugewiesen wird. In Schritt 603 wählt die Konstruktionseinrichtung die nächste Signalnummer aus, die mit 1 beginnt. Wenn in Schritt 604 die ausgewählte Nummer größer als die Anzahl der zugewiesenen Signale ist, kehrt die Konstruktionseinrichtung zurück, anderenfalls fährt die Konstruktionseinrichtung mit Schritt 605 fort. In Schritt 605 ruft die Konstruktionseinrichtung einen Zeiger auf das Primitiv-Senkenanschluss-Objekt ab, das dem nummerierten Signal-Objekt entspricht, und ruft einen Zeiger auf das Signal-Objekt selbst ab. Die Konstruktionseinrichtung ruft diese Zeiger durch Aufrufen der Funktion zum Holen eines Zuweisungszeigers des Senkenan schluss-Objekts ab. In Schritt 606 ruft die Konstruktionseinrichtung einen Zeiger auf das Primitiv-Quellenanschluss-Objekt für das entsprechende Signalanschluss-Objekt auf. In Schritt 607 ruft die Konstruktionseinrichtung einen Zeiger auf das Senkenanschluss-Objekt des Primitiv-Quellenanschluss-Objekts auf. Wenn in Schritt 608 das Primitiv-Senkenanschluss-Objekt der Primitivschaltung des Primitiv-Senkenanschluss-Objekts mit dem Primitiv-Senkenanschluss-Objekt der Primitivschaltung des Primitiv-Quellenanschluss-Objekts identisch ist, besteht eine direkte Verbindung zwischen dem Quellenanschluss und dem Senkenanschluss. Anderenfalls erfolgt die Verbindung durch einen Schaltmechanismus. Wenn die Verbindung durch einen Schaltmechanismus erfolgt, fährt die Konstruktionseinrichtung mit Schritt 609 fort, anderenfalls fährt die Konstruktionseinrichtung mit Schritt 610 fort. In Schritt 609 ruft die Konstruktionseinrichtung eine Funktion zur Verarbeitung einer nicht-direkten Verbindung auf. In Schritt 610 fügt die Konstruktionseinrichtung eine Kennung der Bindung von dem Primitiv-Quellenanschluss zu dem Primitiv-Senkenanschluss zu der Bindungstabelle des virtuellen Schaltungsobjekts hinzu. Eine Bindung stellt die Identität des Primitiv-Quellenanschluss-Objekts und des Primitiv-Senkenanschluss-Objekts dar. Wenn die Verbindung nicht direkt ist, enthält die Bindung darüber hinaus die Identität des Eingangs-Schaltanschluss-Objekts und des Ausgangs-Schaltanschluss-Objekts des Schaltmechanismus. Die Funktion führt dann eine Schleife zu Schritt 603 aus, um das nächste Signal-Objekt zu verarbeiten.
7 ist ein Ablaufdiagramm, das eine Beispielimplementierung einer Funktion zur Verarbeitung einer nicht-direkten Verbindung erläutert. In Schritt 701 ruft die Funktion einen Zeiger auf das Eingangs-Schaltanschluss-Objekt für die Primitivschaltung des Primitiv-Quellenanschluss-Objekts ab. In Schritt 702 ruft die Funktion einen Zeiger auf das Primitiv-Quellenanschluss-Objekt ab. In Schritt 703 ruft die Funktion einen Zeiger auf das Ausgang-Schaltanschluss-Objekt der abgerufenen Primitivschaltung ab. In Schritt 704 erzeugt die Funktion eine Verbindung zwischen dem Eingangs-Schaltanschluss-Objekt und dem Ausgangs-Schaltanschluss-Objekt. Daraufhin kehrt die Funktion zurück.
Diese Funktion gibt einen Zeiger an das Eigner-Objekt des Anschlusses zurück. Der Eigner des Anschlusses ist das Objekt, das direkt einen vollständigen Anschluss enthält. Jeder Anschluss innerhalb der Anschluss-Hierarchie wie dasselbe Eigner-Objekt.
isCompletePort();
Diese Funktion gibt eine Kennung zurück, ob dieser Anschluss ein vollständiger Anschluss ist.
isPrimitivePort();
Diese Funktion gibt eine Kennung zurück, ob dieser Anschluss ein Primitiv-Anschluss ist.
getParentPortPtr(portPtr);
Diese Funktion gibt einen Zeiger auf den Eltern-Anschluss dieses Anschlusses zurück. Der Eltern-Anschluss ist derjenige Anschluss, der der nächsthöhere Anschluss in der Anschluss-Hierarchie ist.
getNumberOfChildPorts(number);
Diese Funktion gibt die Anzahl der Kind-Anschlüsse dieses Anschlusses zurück.
getChildPortPtr(number, portPtr);
Diese Funktion gibt einen Zeiger auf den Kind-Anschluss zurück, der durch den weitergeleiteten Anschluss bezeichnet wird.
Diese Funktion gibt eine Kennung zurück, ob dieser Senkenanschluss mit einem Stream verbunden ist.
getAvStreamPtr(streamPtr);
Diese Funktion gibt einen Zeiger auf den Stream zurück, mit dem dieser Senkenanschluss verbunden ist.
assignStream(streamPtr);
Diese Funktion benachrichtigt einen Senkenanschluss darüber, dass er die Signale innerhalb eines Streams zu berücksichtigen hat, um sie einem Primitiv-Senkenanschluss zuzuweisen.
unassignStream();
Diese Funktion macht die Zuweisung rückgängig.
getNumberOfAssignments(number);
Diese Funktion gibt die Anzahl an Zuweisungen zwischen einem Signal und einem Primitiv-Senkenanschluss zurück, die während der Zuweisung vorgenommen wurden.
getAssignmentsPtrs(number, assignedSignalPtr, toPrimitivePortPtr);
Dieser Funktion wird eine Zuweisungsnummer zugeleitet, und sie gibt eine Kennung des Signals zurück, das dem Primitiv-Anschluss zugewiesen ist.
connectToAssignedStream();
Diese Funktion wird eingesetzt, um einen vollständigen Senkenanschluss und sein Behältnis über den zugewiesenen Stream zu benachrichtigen, so dass jeglicher Vorgang, der für die Verbindung geeignet ist, wie zum Beispiel das Einschalten der Ausgangskomponente ausgeführt werden kann.
Diese Funktion gibt die Verwendung des Signals zurück. Die Verwendung kann zum Beispiel Audio links oder das Rot eines RGB-Signals sein.
getSignalFormat(format);
Diese Funktion gibt das Format des Signals zurück. Das Format kann zum Beispiel 601 Video oder AES Audio sein.
getParentStreamPtr(streamPtr);
Diese Funktion gibt einen Zeiger auf den Stream zurück, der diesem Signal übergeordnet ist. Das heißt, auf den Primitiv-Stream, der das Signal trägt.
getSourcePortPtr(sourcePortPtr);
Diese Funktion gibt einen Zeiger auf den Primitiv-Quellenanschluss zurück, der dieses Signal ausgibt.
Diese Funktion gibt eine Kennung zurück, ob dieser Stream ein vollständiger Stream ist.
lsPrimitiveStream();
Diese Funtion gibt eine Kennung zurück, ob dieser Stream ein Primitiv-Stream ist.
getParentStreamPtr(streamPtr);
Diese Funktion gibt einen Zeiger auf den Stream zurück, der diesem Stream übergeordnet ist.
getNumberOfChildStreams(number);
Diese Funktion gibt die Anzahl der Kind-Streams dieses Streams zurück.
getChildStreamPtr(number, streamPtr);
Diese Funktion gibt einen Zeiger auf den nummerierten Kind-Stream dieses Streams zurück.
getSourcePortPtr(sourcePortPtr);
Diese Funktion gibt einen Zeiger auf den Quellenanschluss zurück, der diesen Stream erzeugt. Der Quellenanschluss befindet sich in seiner Hierarchie auf derselben Ebene wie dieser Stream in seiner Hierarchie.
getSourceProgramPtr(sourceProgramPtr);
Diese Funktion gibt einen Zeiger auf das Quellen-Programm zurück, das diesen Stream erzeugt.
getSignalPtr(signalPtr);
Diese Funktion gibt einen Zeiger auf das Signal in diesem Stream zurück, der ein Primitiv-Stream ist.
Diese Funktion gibt einen Zeiger auf den Primitiv-Quellenanschluss dieser Primitivschaltung zurück.
getSinkPortPtr(sinkPortPtr);
Diese Funktion gibt einen Zeiger auf den Primitiv-Senkenanschluss dieser Primitivschaltung zurück.
getNumberOfConnections(number);
Diese Funktion gibt die Anzahl der Verbindungen von diesem Eingangs-Schaltanschluss zu den Ausgangs-Schaltanschlüssen zurück.
getConnectionPtr(number, outputSwitchPortPtr);
Diese Funktion gibt einen Zeiger auf den nummerierten Ausgangs-Schaltanschluss zurück, der mit diesem Eingangs-Schaltanschluss verbunden ist.
createConnection(outputSwitchPortPtr);
Diese Funktion erzeugt eine Verbindung von diesem Eingangs-Schaltanschluss zu dem weitergeleiteten Ausgangs-Schaltanschluss.
removeConnection(outputSwitchPortPtr);
Diese Funktion entfernt eine Verbindung von diesem Eingangs-Schaltanschluss zu dem weitergeleiteten Ausgangs-Schaltanschluss.
Diese Funktion holt den Eingangs-Schaltanschluss, mit dem dieser Ausgangs-Schaltanschluss verbunden ist.
Diese Funktion gibt einen Zeiger auf den vollständigen Quellenanschluss zurück, der die Signale erzeugt, die durch diese virtuelle Schaltung geleitet werden.
getCompleteSinkPort(sinkPortPtr);
Diese Funktion gibt einen Zeiger auf den vollständigen Quellenanschluss zurück, der die Signale empfängt, die durch diese virtuelle Schaltung geleitet werden.
getNumberOfPrimitiveBindings(number);
Diese Funktion gibt die Anzahl der Bindungen zwischen Primitiv-Quellenanschlüssen und Primitiv-Senkenanschlüssen in dieser virtuellen Verbindung zurück.
getPrimitiveBindingPtrs(number, sourcePortPtr, sinkPortPtr);
Diese Funktion gibt die nummerierte Bindung als einen Zeiger auf den Primitiv-Quellenanschluss und einen Zeiger auf den Primitiv-Senkenanschluss zurück.
Diese Funktion gibt eine Kennung zurück, ob diese Quelle aktiv ist. Ein Quellenanschluss ist aktiv, wenn er imstande ist, ein Signal zu erzeugen.
getAvStreamPtr(streamPtr);
Diese Funktion gibt einen Zeiger auf den Stream zurück, der mit diesem Quellenanschluss verknüpft ist.
getPrimitiveCircuitPtr(primitiveCircuitPtr);
Diese Funktion gibt einen Zeiger auf die Primitivschaltung zurück, die mit diesem Quellenanschluss verknüpft ist, wenn dieser ein Primitiv-Quellenanschluss ist.
getNumberOfVirtualCircuits(number);
Diese Funktion gibt die Anzahl der virtuellen Schaltungen zurück, die mit diesem Quellenanschluss verknüpft sind.
getVirtualCircuitPtr(number, virtualCircuitPtr);
Diese Funktion gibt einen Zeiger auf die nummerierte virtuelle Schaltung zurück.
createVirtualCircuit(toSinkPortPtr);
Diese Funktion erzeugt eine virtuelle Schaltung, die diesen Quellenanschluss mit dem weitergeleiteten Senkenanschluss verbindet.
remove VirtualCircuit(toSinkPortPtr);
Diese Funktion entfernt die virtuelle Schaltung, die den Quellenanschluss mit dem weitergeleiteten Senkenanschluss verbindet.
10 ist ein Blockschaltbild, das die Komponenten eines Unterhaltungszentrums erläutert. Eine Komponente eines Unterhaltungszentrums stellt ein Verhalten bereit, das es einem AV-Programm ermöglicht, einer Player-/Recorder-Komponente zugewiesen zu werden. Wenn ein Programm einem Unterhaltungszentrum zugewiesen wird, führt das Unterhaltungszentrum die Verarbeitung aus, die erforderlich ist, um das Programm in einen Player/Recorder zu laden, zu veranlassen, dass das Programm wiedergegeben wird, und die Ausgangssignale der Player-/Recorder-Komponente an Ausgangskomponenten zu leiten. Ein Unterhaltungszentrum kann mit einem Raum (z. B. mit einem Zim mer in einem Haus) verknüpft sein. Das Unterhaltungszentrum kann darüber hinaus mit mehreren Playern/Recordern und mehreren Ausgangskomponenten wie zum Beispiel einer Anzeigekomponente und einer Lautsprecher-Teilsystem-Komponente verknüpft sein. Das AV-System stellt den verknüpften Raum durch ein Raum-Objekt 1001 dar, stellt die Player-/Recorder-Komponenten durch Player-/Recorder-Objekte 1002 dar und stellt die Ausgangskomponenten durch ein Anzeige-Objekt 1003 und ein Lautsprecher-Teilsystem-Objekt 1004 dar. Ein Unterhaltungszentrum kann einen Standardsatz der Ausgangskomponenten aufweisen. Wenn ein Programm dem Unterhaltungszentrum zugewiesen wird, werden die Ausgangssignale für die Player-/Recorder-Komponente an diese Standard-Ausgabekomponenten geleitet. Das Unterhaltungszentrum steuert das Erzeugen von virtuellen Schaltungen, die zum Ausführen dieses Routings erforderlich sind. Das Unterhaltungszentrum kann darüber hinaus den Ausgangssignalen einer Player-/Recorder-Komponente ermöglichen, dynamisch an verschiedene Ausgangskomponenten geleitet zu werden. Das Unterhaltungszentrum kann zum Beispiel ermöglichen, dass die Ausgabe der Player-/Recorder-Komponente dynamisch zu einer Lautsprechersystem-Komponente geleitet wird, die mit einem anderen Raum verknüpft ist. Um dieses dynamische Routing auszuführen, erzeugt und zerstört das AV-System virtuelle Schaltungen dynamisch. Bei einer Ausführungsform kann das Unterhaltungszentrum für jede seiner Ausgangskomponenten festlegen kann, ob das Routing ermöglicht werden soll, ob es zu benachrichtigen ist, wenn ein Ausgangssignal aufgrund eines Vorgangs außerhalb des Unterhaltungszentrums weitergeleitet wird, und ob eine Benutzerschnittstelle zum Steuern der Ausgangskomponente bereitgestellt wird, an die das Signal geleitet wird. Diese Festlegungen können für jede mit dem Unterhaltungszentrum verknüpfte Ausgangskomponente unterschiedlich sein. Wenn ein Unterhaltungszentrum darüber informiert wird, dass eine seiner Ausgangskomponenten aufgrund eines externen Vorgangs weitergeleitet worden ist (z. B. weil ein anderes Unterhaltungszentrum zu der Ausgangskomponente weitergeleitet hat, wodurch die Benachrichtigung ausgelöst wurde), kann das Unterhaltungszentrum eine zusätzliche Steuereinheit des Players/Recorders werden. Ein Unterhaltungszentrum kann darüber hinaus Eigenschaftsbenachrichtigungen bereitstellen, wenn sich die Eigenschaften seiner verknüpften Player-/Recorder-Komponenten oder Ausgangskomponenten ändern. Das Unterhaltungszentrum kann zum Beispiel eine entsprechende Benutzerschnittstellenkomponente darüber benachrichtigen, dass die Pause-Taste an einer Player-/Recorder-Komponente gedrückt worden ist. Ein Unterhaltungszentrumsobjekt kann eine Benutzerschnittstellenkomponente bereitstellen, die geeignet ist, die Benutzerschnittstelle der mit dem Unterhaltungszentrum verknüpften Eingangskomponenten und Ausgangskomponenten zu steuern.
11 stellt ein Blockschaltbild dar, das verschiedene Komponenten des AV-Systems erläutert. Das AV-System umfasst Player-/Recorder-Objekte 1101, Anzeige-Objekte 1102, Lautsprechersystem-Objekte 1103, Medienmanager-Objekte 1104 und Programmobjekte 1105. Mit einem Player-/Recorder-Objekt sind ein oder mehrere vollständige Quellenanschluss-Objekte verknüpft, und es können ein oder mehrere vollständige Senkenanschluss-Objekte mit ihm verknüpft sein. Mit jedem Ausgangs-Objekt sind ein oder mehrere vollständige Senkenanschlüsse verknüpft. Ein Player-/Recorder-Objekt entspricht üblicherweise einer physikalischen Player-/Recorder-Komponente wie zum Beispiel einem Laserdisc-Player. Das Player-/Recorder-Objekt stellt ein Verhalten zum Laden eines AV-Programms in die Player-/Recorder-Komponente bereit. Ein Player-/Recorder-Objekt stellt darüber hinaus ein Verhalten bereit, das es ermöglicht, dass Befehle an die Player-/Recorder-Komponente gesendet werden. Nachdem eine Laserdisc geladen worden ist, kann zum Beispiel ein Start-, Pause- oder Stop-Befehl über das Player-/Recorder-Objekt an die Player-/Recorder-Komponente gesendet werden. Das Player-/Recorder-Objekt stellt darüber hinaus das Verhalten zum Feststellen bereit, ob ein bestimmtes AV-Programm in die Player-/Recorder-Komponente geladen werden kann. Ein Player-/Recorder-Objekt kann darüber hinaus weiteres Verhalten bereitstellen, das auf die Eigenschaften der entsprechenden Player-/Recorder-Komponente zugeschnitten ist.
Die Ausgangs-Objekte, die den Ausgangs-Komponenten entsprechen, stellen ein Verhalten bereit, das die Kennung eines Senkenanschluss-Objekts zurückgibt, das zum Zuweisen der mit einem vorgegebenen Stream-Objekt verknüpften Signale geeignet ist. Ein Lautsprechersystem-Objekt, dem ein Stream zugeleitet wird, der sowohl Video- als auch Audiosignale umfasst, würde zum Beispiel eine Kennung zurückgeben, dass nur Audio-Senkenanschlüsse zuzuweisen sind. Die Ausgangs-Objekte können darüber hinaus zusätzliches Verhalten bereitstellen, das für den Typ der Ausgangs-Komponente kennzeichnend ist. Ein Anzeige-Objekt kann zum Beispiel ein Verhalten zum Ein- und Ausschalten der Anzeige und zum Steuern des Kontrasts der Anzeige bereitstellen. Ein Lautsprechersystem-Objekt kann ein Verhalten zum Steuern der Lautstärke, für Entzerrerfunktionen und für Mehrkanaltonsystem-Steuerungen bereitstellen. Dieses zusätzliche Verhalten kann Teil der Basisobjektklasse sein oder kann durch eine Ableitung dieser Basisobjektklasse bereitgestellt werden.
Ein Programmpool-Objekt stellt eine Zusammenstellung von AV-Programmen dar. Jedes AV-Programm verfügt über ein entsprechendes Programmobjekt. Ein AV-Programm ent spricht konzeptionell einem Medium, das durch eine Player-/Recorder-Komponente wiedergegeben werden kann. Ein AV-Programm kann zum Beispiel die durch einen bestimmten Fernsehkanal bereitgestellte Zuführung, auf einer CD gespeicherte Noten, einen auf einer Laserdisc gespeicherten Film und so weiter darstellen. Diese AV-Programme können hierarchisch gegliedert sein, um komplexere AV-Programme darzustellen. Ein AV-Programm kann zum Beispiel ein Unter-AV-Programm, das der Zuführung von einem Fernsehkanal entspricht, und ein Unter-AV-Programm, das der Ausgabe eines Computerprogramms entspricht, enthalten. Folglich können AV-Programme beliebig komplexe Multimediaprogramme darstellen. Das AV-System stellt ein AV-Programm durch ein Programmobjekt dar. Ein Programmobjekt stellt das Verhalten bereit, um die Hierarchie der durch das Programmobjekt dargestellten AV-Programme zu durchsuchen, ermöglicht das Zuweisen einer Player-/Recorder-Komponente zu dem AV-Programm und stellt ein Verhalten bereit, das dem Laden des AV-Programms in die Player-/Recorder-Komponente entspricht. Ein Programmobjekt weist darüber hinaus eine Programm-ID auf, die beschreibende Informationen über das AV-Programm bereitstellt. Beschreibende Informationen können zum Beispiel den Titel des Films beinhalten, den das AV-Programm darstellt. Ein Programmobjekt speichert die Position des Mediums, das dem AV-Programm entspricht. Wenn das AV-Programm zum Beispiel einer Laserdisc in einem bestimmten Laserdisc-Stapel entspricht, würde die Position den Stapel und den Schlitz der Laserdisc innerhalb des Stapels kennzeichnen. Bei einer Ausführungsform wird die Position als ein Weg innerhalb einer Hierarchie von Positionen dargestellt. Ein Programmobjekt speichert die Kennung eines Eigners, der das Programmpool-Objekt sein kann, in dem sich das Programmobjekt befindet. Ein Programmobjekt ermöglicht das Abrufen seiner Kind-Programmobjekte und kann das Feststellen bestimmter Kriterien ermöglichen, so dass nur Kinder, die den Kriterien entsprechen, zurückgegeben werden. Ein Programmobjekt kann darüber hinaus das Abrufen seines Eltern-Programmobjekts ermöglichen. Bei einer Ausführungsform kann das Eltern-Programmobjekt durch den beinhaltenden (in den Ansprüchen als Programmangebot bezeichneten) Programmpool durch Bereitstellen der Position des Programmobjekts für den Programmpool abgerufen werden. Mit einem Programmobjekt ist ein Programmtyp verknüpft. Der Programmtyp bestimmt einen Weg durch eine Hierarchie von Programmtypen. Die Hierarchie von Programmtypen wird unten ausführlich beschrieben.
Bei einer Ausführungsform stellt das AV-System eine Fähigkeit zum Zerlegen einer Programm-ID in viele verschiedene Typen von Verweisen bereit. Das AV-System kann zum Beispiel eine Funktion zum Holen eines Programmobjekts bereitstellen, die eine Pro gramm-ID eingibt und einen Verweis zu einem entsprechenden Programmobjekt zurückgibt. Das AV-System kann darüber hinaus eine Funktion zum Holen der Programmgattung bereitstellen, die eine Programm-ID eingibt und einen Satz von Programmobjekten in derselben Gattung zurückgibt. Eine Programm-ID für ein Country-Musikstück würde, wenn sie für die Funktion zum Holen der Programmgattung bereitgestellt würde, zum Beispiel Verweise zu anderen Country-Musikstücken entsprechenden Programmobjekten zurückgeben. Um solche mehrfach auflösenden Verweise umzusetzen, können die Funktionen auf das mit der Programm-ID verknüpfte Programmobjekt zugreifen, um Informationen über seine Gattung abzurufen.
Ein Programmobjekt kann Alternativ-Schnittstellen für die Zustandserhaltung bereitstellen. Ein Programmobjekt kann zum Beispiel eine Schnittstelle zum Hinzufügen und Löschen von Eigenschaften des Programmobjekts und zum Einstellen von Eigenschaften des Programmobjekts bereitstellen. Eine Alternativ-Schnittstelle kann darüber hinaus das Hinzufügen und Löschen von Kind-Programmobjekten oder das Löschen des Programmobjekts selbst bereitstellen. Diese Schnittstellen können für den Typ des durch das Programmobjekt dargestellten AV-Programms kennzeichnend sein.
Ein Programmpool weist ein entsprechendes Programmpool-Objekt auf. Ein Programmpool-Objekt stellt einen Zugriffsanschluss für jeden Client bereit, der auf den Programmpool zugreift. Das Programmpool-Objekt stellt eine Funktion bereit, die eine Programm-ID empfängt und einen Verweis zu einem dieser Programm-ID entsprechenden Programmobjekt zurückgibt. Ein Programmpool-Objekt ermöglicht darüber hinaus einen datenbankcursor-artigen Zugriff auf die Programmobjekte. Es kann zum Beispiel eine Abfrage gestellt werden, die die Kriterien für Programmobjekte bestimmt. Die mit diesen Kriterien übereinstimmenden Programmobjekte werden in einem Ergebnissatz bereitgestellt. Der Client kann unter Verwendung von Verfahren wie zum Beispiel dem Vorrücken zum nächsten Programmobjekt auf den Ergebnissatz zugreifen, Verweise für das aktuelle Programmobjekt erlangen und einen Satz von Verweisen für die Programmobjekte in dem Ergebnissatz zurückgeben. Bei einer Ausführungsform kann der Ergebnissatz einer Abfrage bei einem Client zwischengespeichert werden, um die Kommunikationsvorgänge mit dem Client in dem Programmpool zu verringern. Der Programmpool kann darüber hinaus den Zwischenspeicher des Clients als den Satz von Programmen, die mit den Veränderungen der Kriterien übereinstimmen, automatisch aktualisieren. Bei einer Ausführungsform stellt der Programmpool einen Zugriffskontrollmechanismus bereit, um den Zugriff durch bestimmte Clients zu beschränken. Der Programmpool kann den Phantom- Objektmechanismus, wie in „Method and System for Tracking Clients" beschrieben, einsetzen.
Der Medienmanager stellt einen Mechanismus zum Verwaltung von Medien an ihrer Position und zum Bereitstellen eines Player-/Recorder-Objekts für die Medien selbst bereit. Ein Medienmanager-Objekt kann zum Beispiel einem Mehrfach-Laserdisc-Stapel entsprechen. Das Medienmanager-Objekt stellt eine Programmladefunktion bereit, an die ein Programmobjekt weitergegeben wird und die ein Player-/Recorder-Objekt mit diesem geladenen Programm zurückgibt. Ein Medienmanager kann hierarchisch gegliedert sein. Das heißt, ein Medienmanager-Objekt kann Kind-Medienmanager-Objekte mit einer beliebigen Zahl an Verschachtelungsebenen aufweisen. Jedes Eltern-Medienmanager-Objekt kann eine zugehörige Positionstabelle aufweisen. Die Positionstabelle bildet die Position eines Programms auf das Medienmanager-Objekt ab, das für das Zurückgeben des Player-/Recorder-Objekts für dieses Programmobjekt zuständig ist. Ein Medienmanager-Objekt, das über kein Kind-Objekt verfügt, kann die Position des Programmobjekts verarbeiten, um zu bestimmen, welcher Player/Recorder mit dem Programmobjekt verknüpft werden soll. Wenn zum Beispiel ein Medienmanager-Objekt einen Mehrfach-Laserdisc-Stapel darstellt, kann das Medienmanager-Objekt die Position, die mit diesem Programmobjekt verknüpft ist, dazu verwenden zu bestimmen, welcher Schlitz innerhalb des Stapels die Medien für dieses Programm enthält.
12 ist ein Ablaufdiagramm, das das Zuweisen eines Programms zu einem Unterhaltungszentrum erläutert. In Schritt 1201 ruft die Funktion eine Funktion zum Auswählen eines bestimmten Programmobjekts auf. Die aufgerufene Funktion gibt einen Zeiger auf das Programmobjekt zurück. In Schritt 1202 ruft die Funktion die eingestellte aktuelle Programmfunktion des Unterhaltungszentrums-Objekts auf, wobei der Zeiger auf das Programmobjekt weitergegeben wird. Daraufhin ist die Verarbeitung abgeschlossen.
13 ist ein Ablaufdiagramm einer Funktion zum Auswählen eines Programms. Diese Funktion kann eine Benutzerschnittstelle anzeigen, die es einem Benutzer ermöglicht, die Programme in einem Programmpool zu durchsuchen. Die Benutzerschnittstelle kann dem Benutzer ermöglichen, verschiedene Suchkriterien zu bestimmen. Die Benutzerschnittstelle kann zum Beispiel dem Benutzer ermöglichen, die Musikrichtung von Interesse zu bestimmen. In Schritt 1301 ermöglicht die Funktion dem Benutzer, ein Programm aus dem Programmpool auszuwählen. In Schritt 1302 setzt die Funktion den Rückgabezeiger auf einen Zeiger auf ein Programmobjekt, das das Programm darstellt. Daraufhin kehrt die Funktion zurück.
14 ist ein Ablaufdiagramm, das eine Beispielimplementierung einer eingestellten aktuellen Programmfunktion eines Unterhaltungszentrumsobjektes darstellt. An diese Funktion wird ein Zeiger auf ein Programmobjekt weitergeleitet, und sie bewirkt das Laden dieses Programms innerhalb des Unterhaltungszentrums. In Schritt 1401 ruft die Funktion eine Funktion zum Abrufen eines geladenen Player-/Recorder-Objekts auf. Die Funktion gibt einen Zeiger auf das Programmobjekt weiter, und es wird ein Zeiger auf ein Player-/Recorder-Objekt, das mit dem Programm geladen wird, an sie zurückgegeben. In Schritt 1402 ruft die Funktion die Funktion zum Holen der aktuellen Quelle des Player-/Recorder-Objekts auf. Die aufgerufene Funktion gibt einen Zeiger auf den vollständigen Quellenanschluss für das Player-/Recorder-Objekt zurück. In Schritt 1403 ruft die Funktion die Funktion zum Holen des Streamzeigers des Quellenanschluss-Objekts auf, um einen Zeiger auf den vollständigen Stream für dieses Quellenanschluss-Objekt abzurufen. In den Schritten 1404–1407 führt die Funktion eine Schleife aus, wobei sie die mit dem Unterhaltungszentrum verknüpften Ausgangskomponenten auswählt und eine virtuelle Schaltung von der Player-/Recorder-Komponente zu den Ausgangskomponenten erzeugt. Wie oben beschrieben, kann ein Unterhaltungszentrum einen Standardsatz an Ausgangskomponenten aufweisen. In Schritt 1404 wählt die Funktion die nächste Ausgangskomponente aus. Wenn bereits alle Ausgangskomponenten ausgewählt worden sind, kehrt die Funktion in Schritt 1405 zurück; anderenfalls fährt die Funktion mit Schritt 1406 fort. In Schritt 1406 fordert die Funktion die ausgewählte Ausgangskomponente auf, ein Senkenanschluss-Objekt zurückzugeben, das für den Stream geeignet ist. Die Funktion ruft eine Funktion zum Holen des Senkenanschlusses des der ausgewählten Ausgangskomponente entsprechenden Ausgangsobjekts auf. In Schritt 1407 ruft die Funktion die Funktion zum Erzeugen einer virtuellen Schaltung des Quellenanschluss-Objekts auf, wobei ein Zeiger auf das Senkenanschluss-Objekt weitergegeben wird. Diese aufgerufene Funktion erzeugt eine virtuelle Schaltung von dem Quellenanschluss zu dem Senkenanschluss. Die Funktion führt dann eine Schleife zu Schritt 1404 aus, um die nächste Ausgangskomponente auszuwählen.
15 ist ein Ablaufdiagramm einer Beispielimplementierung einer Funktion zum Holen eines geladenen Player-/Recorder-Objekts. Dieser Funktion wird ein Zeiger auf ein Programmobjekt zugeleitet, und sie gibt einen Zeiger auf ein Player-/Recorder-Objekt zurück. In Schritt 1501 ruft die Funktion die Position des Programmobjekts ab. Wenn in Schritt 1502 die Position angibt, dass bereits eine Player-/Recorder-Komponente mit diesem Programmobjekt verknüpft ist, fährt die Funktion mit Schritt 1503 fort, anderenfalls fährt die Funktion mit Schritt 1504 fort. In Schritt 1503 ruft die Funktion die Selbstladefunktion des Programmobjekts auf und empfängt dafür einen Zeiger auf ein geladenes Player-/Recorder-Objekt. In Schritt 1504 holt die Funktion ein Player-/Recorder-Objekt, das für das Unterhaltungszentrum geeignet ist. In Schritt 1505 ruft die Funktion eine Programmladefunktion des Player-/Recorder-Objekts auf, wobei der Zeiger auf das Programmobjekt weitergegeben wird. Daraufhin kehrt die Funktion zurück.
16 ist ein Ablaufdiagramm einer Beispielimplementierung der Selbstladefunktion des Player-/Recorder-Objekts. Dieser Funktion wird ein Zeiger auf ein Programmobjekt zugeleitet, das in die Player-/Recorder-Komponente geladen werden soll. In Schritt 1601 ruft die Funktion eine Programmladefunktion des Medienmanager-Objekts auf, wobei ein Zeiger auf das Programmobjekt weitergegeben und dafür ein Zeiger auf einen Player/Recorder empfangen wird. In Schritt 1602 ruft die Funktion eine Programmladefunktion des Player-/Recorder-Objekts auf, wobei der Programmzeiger weitergegeben wird, und kehrt dann zurück.
17 ist ein Ablaufdiagramm einer Beispielimplementierung der Programmladefunktion eines Player-/Recorder-Objekts. Dieser Funktion wird ein Zeiger auf ein Programmobjekt zugeleitet, und sie bewirkt das Laden des Programms in die Player-/Recorder-Komponente. In Schritt 1701 bestimmt die Funktion einen vollständigen Quellenanschluss, der für das weitergegebene Programm geeignet ist. Eine Player-/Recorder-Komponente kann mehr als einen vollständigen Quellenanschluss aufweisen. Ein Player-/Recorder-Objekt kann zum Beispiel eine vollständige Quelle, die einem RGB-Signal entspricht, und einen weiteren vollständigen Quellenanschluss aufweisen, der einem digitalen Videosignal entspricht. In Schritt 1702 weist die Funktion das Programmobjekt dem Player-/Recorder-Objekt zu. In Schritt 1703 bestimmt die Funktion die Verwendung, das Format und den Anschlusstyp für die Primitivanschlüsse des ausgewählten Quellenanschlusses. In Schritt 1704 ruft die Funktion die Funktion zum Setzen eines Signals des vollständigen Quellenanschlusses auf, wobei sie die Verwendung, das Format und den Anschlusstyp weitergibt. Die aufgerufene Funktion setzt die Verwendung, das Format und den Anschlusstyp für jeden Primitiv-Quellenanschluss. In Schritt 1705 benachrichtigt die Funktion das Programmobjekt davon, das es nun geladen ist. Daraufhin kehrt die Funktion zurück.
18 ist ein Ablaufdiagramm einer beispielhaften Programmladefunktion eines Medienmanager-Objekts. Diese Beispielfunktion beschreibt die Verarbeitung, die ausgeführt werden kann, wenn der Medienmanager über Kind-Medienmanager-Objekte verfügt. Dieser Funktion wird ein Zeiger auf ein Programmobjekt zugeleitet, und sie gibt einen Zeiger auf ein Player-/Recorder-Objekt zurück. In Schritt 1801 ruft die Funktion die Funktion zum Holen einer Position des Programmobjekts auf, um die Position der Medien, wie durch das Programmobjekt angegeben, abzurufen. In Schritt 1802 durchsucht die Funktion die Positionstabelle nach einem Medienmanager-Objekt, das die dem Programmobjekt entsprechenden Medien verwaltet. In Schritt 1803 ruft die Funktion die Programmladefunktion des lokalisierten Medienmanager-Objekts auf und kehrt dann zurück.
19 ist ein Ablaufdiagramm einer weiteren beispielhaften Programmladefunktion des Medienmanager-Objekts. Diese Beispielfunktion beschreibt die Verarbeitung, die ausgeführt werden kann, wenn das Medienmanager-Objekt nicht über Kind-Medienmanager-Objekte verfügt. In Schritt 1901 ruft die Funktion die Position von dem Programmobjekt ab und sucht die mit dieser Position verknüpften Medien. In Schritt 1902 initialisiert die Funktion ein Player-/Recorder-Objekt für diese Medien. In Schritt 1903 setzt die Funktion einen Rückgabezeiger so, dass er auf das Player-/Recorder-Objekt zeigt. Daraufhin kehrt die Funktion zurück.
Ein Kenner der Technik würde erkennen, dass verschiedene Modifizierungen an der vorliegenden Erfindung vorgenommen werden können. Dementsprechend ist die Erfindung nicht auf die spezifischen Ausführungsformen beschränkt, sondern stattdessen wird der Umfang der Erfindung durch die folgenden Ansprüche spezifiziert.
ANHANG 1
Übersicht
Das Haussteuersystem (House Control System – HCS) besteht aus mehreren Teilsystemen wie zum Beispiel HLK, Beleuchtung und Audio/Video. Jedes Teilsystem ist zuständig für das Verwalten seiner eigenen Ressourcen und für das Bereitstellen von Services für Endbenutzer des HCS-Systems.
Die verschiedenen HCS-AV-Teilsystemkomponenten stellen für den Benutzer einen vollständigen und einheitlichen Zugriff auf die verschiedenen AV-Ressourcen bereit, die für das HCS verfügbar sind.
Die Physikalische Umgebung
Bevor wir ins Detail gehen, betrachten wir die physikalische AV-Umgebung, in der das HCS besteht, wie es verwaltet wird und was es für den Benutzer verkörpert.
Im Allgemeinen sollte das physikalische AV-System als ein Satz von „vernetzten" Vorrichtungen betrachtet werden, die dynamisch zusammengeschaltet und programmatisch gesteuert werden können.
Das „AV-Netzwerk"
Das AV-Netzwerk besteht aus einem oder mehreren analogen AV-Matrixschaltern, durch die die verschiedenen Eingänge und Ausgänge der AV-Vorrichtungen verbunden sind. Diese Schalter werden zusammengefasst dazu verwendet, temporäre Verbindungen zwischen diesen Vorrichtungen zu bilden, um AV-Signale zwischen ihnen weiterzuleiten.
Das AV-Netzwerk könnte erweitert werden, um das digitale Routing von AV-Informationen über Hochgeschwindigkeits-Netzwerke wie ATM einzubeziehen. Dieser Umstand muss unter dem Gesichtspunkt der Architektur berücksichtigt werden.
Die AV-Vorrichtungen
Es sind verschiedene Arten von AV-Vorrichtungen vorgesehen. Diese umfassen:

• Verschiedene Arten von Lautsprechersystemen (Umgebung, Stereo, Theater...) – diese umfassen Verstärker.
• Verschiedene Typen von Videoanzeigen,
• Fernbedienungen (tragbare Mäuse),
• Selbständige Recorder und Player (z. B. VCR, CD...),
• Gemeinsame HF-Rundfunktuner (TV & Radio),
• Andere interne AV-Quellen (wie zum Beispiel Sicherheitskameras),
• Kabel-"Tuner" für Audio- und AV-Übertragung (DMX, TCI...) und
• Gemeinsame Pools von AV-Programmgestaltung: • Audio-CD-Jukeboxen • LaserDisc-Jukeboxen (AV), • VHS-Band-Jukeboxen und • Standbildbibliotheken.

Das Ziel des HCS-AV-Modells ist, das Verhalten dieser Ressourcen bis zu einem Punkt zu verallgemeinern, dass der Endbenutzer mit ihnen ebenso wie mit den neuen Vorrichtungstypen (Hardware und Software) auf eine einheitliche, natürliche Weise umgehen kann.
Die Sicht des HCS-Benutzers
Es ist nicht zweckmäßig, dass der HCS-Benutzer auf der physikalischen Ebene des AV-Teilsystems Einfluss nimmt. Das Ziel ist daher, natürliche Abstraktionen auf hoher Ebene bereitzustellen, durch die der Benutzer interagiert. Um dies zu erreichen, gibt es mehrere andere Zwischenabstraktionen zwischen den physikalischen Einheiten (Vorrichtungen) und dem Benutzer, die definiert und implementiert werden müssen. Um unser Denken wie auch das Modell selbst zu gliedern, wird ein geschichtetes Funktionalitätsmodell eingesetzt.
Das HCS-AV-Funktionalitätsmodell

Das folgende Modell wird zum Klassifizieren der verschiedenen Funktionalitätsebenen innerhalb des HCS-AV-Teilsystems verwendet.

Schicht	Zweck
Serviceschicht	Stellt Endbenutzer-Zugriff und -Steuerung Ober das gesamte AV-Teilsystem bereit. Stellt eine natürliche und vereinheitlichte Perspektive der AV-Ressourcen bereit. Komponenten auf dieser Schicht sind häufig auf die UI (Benutzerschnittstelle) bezogen.
Verwaltungsschicht	Stellt die Verwaltung von bestimmten Arten von Ressourcen (physikalisch oder nicht physikalisch) bereit. Die Absicht ist, die spezifischen Kenntnisse über AV-Ressourcen, Routing usw. auf diese oder tiefere Schichten zu beschränken. Des Weiteren ist die Absicht, dass die Komponenten der Serviceschicht die Verwaltungsschicht dazu „verwenden", Benutzeranforderungen zu sammeln und auszuführen (mehr darüber später). Es ist sehr gut möglich, dass diese Schicht direkt mit dem Benutzer über UI-Komponentenobjekte interagiert, die innerhalb von Service-UIs dargestellt werden.
Vermittlungsschicht	Die Komponenten dieser Schicht sind zuständig für das Verwalten und Darstellen der temporären Verbindungen zwischen AV-Komponenten, die an der Ausführung einer Benutzeranforderung beteiligt sind. Diese Schicht umfasst darüber hinaus die Komponenten, die das eigentliche AV-„Koppelfeld” implementieren. Das gesamte Feld wird unabhängig davon, wie komplex es ist, „zusammengeklebt" und als einzelne dünnbesetzte 2D-Schaltmatrix (Eingänge gegenüber Ausgängen) dargestellt. Darüber hinaus bildet diese Schicht die AV-Kopplungskarte des gesamten AV-Systems (Schaltungen, Anschlüsse...) ab.

Alle diese verschiedenen AV-Objekte, die die AV-Software-Implementierung ausmachen, bilden ihr Verhalten auf eine dieser Ebenen ab. Sobald alle diese Komponenten-Objektklassen eingeführt sind, wird jede Ebene dieses Verweises erneut dargestellt und angegeben, welche Komponenten diese Funktionalitätsebene implementieren.
Überblick: Das HCS-Raummodell
Die grundlegende vereinheitlichende, die gewissermaßen „konkrete" Objektklasse in dem HCS-Modell ist der HCS-Raum (HcsSpace). HCS-Räume stellen die tatsächlichen (physikalischen) räumlichen Einheiten (Bereiche, Zimmer, Seitenflügel, Etagen, Gebäude ...) und ihre Beziehung untereinander dar. Dieses Raummodell bildet die „Grundlage" für andere Objekte innerhalb des HCS-Systemmodells. Bevor im Einzelnen auf das AV-Objektmodell eingegangen wird, ist möglicherweise ein kleiner Überblick hilfreich.
Es gibt eine Objektklasse mit der Bezeichnung HCS-Raumservice (HcsSpatialService). HCS-Raumservices werden innerhalb von HCS-Rauminstanzen angesammelt. Sie haben den Zweck, das Gesamtverhalten eines bestimmten HCS-Raums über die bloße Eigenschaft, ein Raum zu sein, hinaus zu erweitern. Wenn als Beispiel ein gegebener Raum die Beleuchtungssteuerung ermöglichen soll, wäre in diesem Raum der beleuchtungsbezogene HCS-Raumservice vorhanden. Dasselbe würde für räumliches AV-Verhalten gelten.
Um diese Beschreibung des auf den Raum konzentrierten Verhaltens des HCS zu vervollständigen, wird untersucht, wie UIs in diesem Zusammenhang implementiert werden. Zunächst werden alle physikalischen Punkte einer HCS-/Benutzer-Interaktion als ein HCS-Benutzerkontrollpunkt-Objekt (HcsUserControlPoint) gestaltet und zu einem beliebigen festgelegten Zeitpunkt mit genau einem HCS-Raum verknüpft. Es kann jedoch mehrere HCS-Benutzerkontrollpunkte geben, die mit einem einzelnen HCS-Raum verknüpft sind. Das Ziel ist, dass diese Beziehung die physikalische Beziehung zwischen diesen Einheiten gestalten soll.
Für jeden unterschiedlichen Typ des HCS-Benutzerkontrollpunktes wird eine spezifische Ableitung implementiert. Der Zweck ist, dass eine Ableitung genau weiß, was sie „ist" und wie sie sich entsprechend verhalten muss. Um dies deutlich zu machen: Ein HCS-Benutzerkontrollpunkt vom Typ „TV" verhält sich wie ein TV-Gerät, das das Stattfinden von HCS-Steuerung innerhalb dieses Zusammenhangs zulässt. Dagegen würde ein HCS-Benutzerkontrollpunkt vom Typ eines Kontaktbildschirms einen viel direkteren HCS-Zugriff ermöglichen, da seine grundlegende Zweckbestimmung darin besteht, eine allgemeine Verwendung des HCS-Systems bereitzustellen.
Ein weiterer wichtiger Umstand bezüglich HCS-Benutzerkontrollpunkten ist, dass sie im Grunde jenseits ihres normalen Verhaltens (wie das, ein TV-Gerät zu sein) nur UI-Rahmen für die HCS-Raumserviceinstanzen sind, die in diesem HCS-Raum vorhanden sind und zu denen die betreffenden HCS-Benutzerkontrollpunkte gehören.
Bisher ist der HCS-Benutzerkontrollpunkt die einzige wirkliche vorgestellte Komponente vom Typ einer UI. Aus einer UI-Perspektive ist dies wiederum in Wirklichkeit nur ein Rahmen für andere untergeordnete UIs. Andere Objekte (Ressourcen) in dem System wie zum Beispiel HCS-Raumservices und gemeinsame AV-Vorrichtungen in den Unterhaltungszentren müssen in der Lage sein, ihre UIs letzten Endes innerhalb des Rahmens spezifischer Arten von HCS-Benutzerkontrollpunkten (TV, PC, Kontaktbildschirme...) darzustellen. Dies erfolgt nicht direkt, sondern eher durch als HCS-Ressourcen-Benutzersteuerungen (HcsResUserCntls – RUC) bezeichnete Ersatzobjekte, die ebenfalls in demselben Prozessraum vorhanden sind wie der HCS-Benutzerkontrollpunkt, durch den die UI der Ressource dargestellt wird. Man kann sich als eine Möglichkeit Ressourcen, die über eine UI verfügen, als einen Satz von Objekten vorstellen. Wobei die erste die tatsächliche Ressource selbst ist und die anderen die unterschiedlichen Typen von HCS-Ressourcen-Benutzersteuerungen (UI-Komponenten) für die verschiedenen Typen von HCS-Benutzerkontrollpunkten sind, durch die diese Ressource eingesetzt werden kann.
Mit diesem Hintergrund: Der AV-HCS-Raumservice (AV HcsSpatialService) wird als HCS-Unterhaltungszentrum (HcsEntertainmentCenter) bezeichnet. Tatsächlich handelt es sich um eine Ableitung der Objektklasse HCS-Raumservice; und erweitert als solche direkt das Verhalten der HCS-Räume, in denen sie konfiguriert wird. Es können null oder mehr Instanzen eines HCS-Unterhaltungszentrums innerhalb eines vorgegebenen HCS-Raums vorhanden sein. Der übrige Teil dieser Veröffentlichung wie auch der Großteil des AV-Modells und der AV-Implementierung handeln vom Verallgemeinern der physikalischen AV-Vorrichtungen und -Verbindungen bis zu einem Grad, bei dem sie durch ein HCS-Unterhaltungszentrum für den Endbenutzer dargestellt werden können.
Darstellen von räumlichen AV-Vorrichtungen
Zusätzlich zu den Beständen gemeinsamer AV-Hardwareressourcen können in einem Raum außerdem normale (selbständige) Vorrichtungen vorhanden sein. Alle selbständigen Vorrichtungen (z. B. Anzeigen und Medienplayer/-recorder), die physikalisch in ei nem Raum vorhanden sind, werden zu einer Sammlung (HCS-Sammlung – HcsCollection) zusammen gruppiert, die als HCS-AV-Sammlung (HcsAvCollection) bezeichnet wird. HCS-AV-Sammlungen werden in ihrer „besitzenden" HCS-Rauminstanz angesammelt. Angesichts dieser Beziehung kann ein HCS-Raum indirekt alle seine lokalen AV-Komponenten gegenüber anderen HCS-Komponenten kennzeichnen. BEMERKUNG: Gemeinsame Vorrichtungen wie zum Beispiel Jukeboxen fallen NICHT in diese Kategorie – sie werden nicht als lokale Vorrichtungen in jeglichem Raum betrachtet.
Definitionen
Dieser Abschnitt der Veröffentlichung stellt eine Beschreibung des HCS-AV-Objektmodells durch die Definition jeder Objektklasse innerhalb dieses Modells bereit. Einige dieser Objektklassen stellen Dinge auf sehr niedriger Ebene dar wie Kabel und Ähnliches, während andere abstrakte Konzepte wie Informationen darstellen. Ein wichtiger Aspekt ist, dass keine der hier definierten Objektklassen nur ihre (physikalischen) Entsprechungen in der realen Welt, sondern alle auch „Software"-Entsprechungen abbilden sollen.
Am besten lässt sich das gesamte Objektmodell aufnehmen, indem man den Satz an Definitionen zumindest zwei Mal liest. Dies ist aufgrund der Querverweise zwischen verschiedenen Definitionen erforderlich.
Audio-Nideo-Signal
Die Objektklasse AV-Signal (AvSignal) stellt alle tatsächlichen Echtzeit-Audio-/Video-Informationen bereit, die innerhalb eines HCS-AV-Netzwerks bezogen, weitergeleitet und gesenkt werden. Diese Objektklasse ist dafür bestimmt, nicht nur analoge Signale, sondern auch „digitale Signale" abzubilden.

BEMERKUNG: AV-Signale werden unter Verwendung von ASN.1-Objekt-IDs gerichtet und hierarchisch klassifiziert (typisiert). AV-Signale sind in dem Sinne gerichtet, dass sie an einem AV-Quellenanschluss (AvSourcePort) entstehen und an einem oder mehreren AV-Senkenanschlüssen (AvSinkPorts) enden. Mehr darüber später.

Audio-/Video-Stream
Die Objektklasse AV-Stream (AvStream) stellt ein „gerichtetes Behältnis" entweder eines AV-Signals oder von untergeordneten AV-Streams dar. Es können nur dann mehrere AV-Streams in einem gemeinsamen Eltern-AV-Stream enthalten sein, wenn die „Unter-AV-Streams" durch irgendeine Beschränkung wie zum Beispiel Synchronisierung zueinander in Beziehung stehen. Ein AV-Stream ist in dem Sinne „gerichtet", dass er an einem AV-Quellenanschluss entsteht und an einem oder mehreren AV-Senkenanschlüssen endet. Die Einschließungsbeziehung eines AV-Streams kann beliebig komplex sein. Beispiel: eine RGB-Audio-/Video-Zuführung:

Definition: Primitiv-AV-Stream: Ein Primitiv-AV-Stream ist ein AV-Stream, der nur ein AV-Signal enthält.
Definition: Vollständiger AV-Stream: Ein vollständiger AV-Stream ist ein AV-Stream, der nicht in einem weiteren AV-Stream enthalten ist.

Im Allgemeinen ist beabsichtigt, dass AV-Streams alle Attribute enthalten, die erforderlich sind, um die AV-Daten, die der AV-Stream darstellt, vollständig zu beschreiben. Dazu gehören einige und möglicherweise ein große Anzahl Textattribute. Dieses Konzept reicht bis zu der Darstellung von Komponentensignalen einer alternativen Form. Zum Beispiel ein AV-Stream, der die analogen Audio- und Videoausgaben aus einem Videorecorder darstellt: Wenn die enthaltenen analogen AV-Signale durch eine MPEG-Codiereinrichtung geleitet würden, wäre(n) das/die von dieser Codiereinrichtung ausgegebene(n) AV-Signal(e) ebenfalls in demselben AV-Stream zusammen mit seinen/ihren analogen Cousins enthalten. Mit anderen Worten, es gibt nach wie vor nur einen AV-Stream, der alle unterschiedlichen Darstellungen (digital und analog) der ursprünglichen Informationen im Hinblick auf AV-Signale enthält.
Audio-/Video-Quellenanschluss
Die Objektklasse AV-Quellenanschluss (AvSourcePort) stellt den Ausgangspunkt eines einzelnen AV-Streams und folglich der AV-Signale, die dieser AV-Stream enthält, dar. Genauer gesagt, AV-Quellenanschlüsse können eine „physikalische" Quelle eines AV-Signals (Primitiv-AV-Stream) oder irgendeine übergeordnete Gruppierung von AV-Quellenanschlüssen darstellen. Die Gruppierungshierarchie von AV-Quellenanschlüssen entspricht der des durch diesen AV-Quellenanschluss „erzeugten" AV-Streams. Wenn die obige AV-RGB-Zuführung als Beispiel angenommen würde: Dann gäbe es einen einzelnen AV-Quellenanschluss auf hoher Ebene, der einen AV-Stream in Form des „RGB-AV-Streams" „erzeugt". Dieser AV-Quellenanschluss würde dann zwei andere AV-Quellenanschlüsse enthalten, die den AV-Streams „Audio-Stream" und „RGB-Video-Stream" entsprechen. Diese hierarchische Einschließungsbeziehung würde bis zu einem Punkt fortgesetzt, an dem vier AV-Quellenanschlüsse vorhanden wären, die alle Primitiv-AV-Streams und folglich alle tatsächlichen „erzeugten" AV-Signale darstellten. Wiederum gilt, dass von jeder Ebene aus betrachtet die Gruppierungsstruktur eines AV-Quellenanschlusses der Gruppierung des AV-Streams entspricht, der an diesem AV-Quellenanschluss erzeugt wird.

Definition: Primitiv-AV-Quellenanschluss: Ein Primitiv-AV-Quellenanschluss erzeugt einen Primitiv-AV-Stream. An Primitive-AV-Quellenanschlüssen sind eigentlich AV-Primitivschaltungen (siehe unten – aber denken Sie im Moment an Kabel) befestigt, in die die entsprechenden AV-Signale eingegeben werden, wenn sie aktiv sind.
Definition: Vollständiger AV-Quellenanschluss: Ein vollständiger AV-Quellenanschluss ist nicht in einem weiteren AV-Quellenanschluss enthalten.

Ein AV-Quellenanschluss kann sich entweder in einem „angeschlossenen" oder in einem „getrennten" Zustand befinden. Während vollständige AV-Quellenanschlüsse sich im angeschlossenen Zustand befinden, gibt es einen oder mehrere verknüpfte virtuelle AV-Schaltungen (mit Multicast-Funktionalität), in die er seinen vollständigen AV-Stream eingibt. Siehe die Definition der virtuellen AV-Schaltung für weiterführende Informationen.
Es ist vorgesehen, dass die AV-Quellenanschluss-Abstraktion die physikalische Quellenanschluss-Hardware ebenso wie „Software"-Quellenanschlüsse von AV-Signalen wie zum Beispiel Softwarekomprimierer und -filter abbildet.
Audio-/Video-Senkenanschluss
Die Objektklasse AV-Senkenanschluss (AvSinkPort) stellt den Abschlusspunkt eines einzelnen AV-Streams dar. Die Gruppierungshierarchie eines AV-Senkenanschlusses entspricht der des AV-Streams, den er senkt. Während die Gruppierungsstrukturen sich entsprechen, sind möglicherweise nicht alle AV-Komponentensignale für den AV-Quellenanschluss zugänglich oder werden von ihm genutzt. Unter Verwendung des Beispiels eines kombinierten VCS-AV-Streams, der über getrennte Audio- und Video-Unter-AV-Streams verfügt: Ein AV-Quellenanschluss an einem Videobildschirm würde den Audio-AV-Stream nicht verwenden, selbst wenn er logisch verfügbar ist.

Definition: Primitiv-AV-Senkenanschluss: Ein Primitiv-AV-Senkenanschluss beendet einen Primitiv-AV-Stream. Unter einem physikalischen Gesichtspunkt ist an einen Primitiv-AV-Senkenanschluss eigentlich eine AV-Primitivschaltung angeschlossen, von der das entsprechende AV-Signal bezogen werden kann.
Definition: Vollständiger AV-Senkenanschluss: Ein vollständiger AV-Senkenanschluss ist nicht in einem weiteren AV-Senkenanschluss enthalten.

Ein AV-Senkenanschluss kann sich entweder in einem „angeschlossenen" oder in einem „getrennten" Zustand befinden. Während vollständige AV-Senkenanschlüsse sich im angeschlossenen Zustand befinden, gibt es eine verknüpfte virtuelle AV-Schaltung (Av-VirtualCircuit), aus der er seinen (einzelnen) vollständigen AV-Stream bezieht.
Es ist vorgesehen, dass die AV-Senkenanschluss-Abstraktion die physikalische Senkenanschluss-Hardware ebenso wie „Software"-Senkenanschlüsse von AV-Signalen für Softwareprozesse abbildet.
Eingangs-Schaltanschlüsse
Die Objektklasse AV-Eingangs-Schaltanschluss (AvInputSwitchPort) leitet ihr grundlegendes Verhalten aus der Klasse AV-Senkenanschluss ab und erweitert dieses Verhalten durch Zulassen einer oder mehrerer „Ausgangs"-AV-Primitivschaltungen, die die internen Koppelfeldwege zu den verschiedenen Ausgangsanschlüssen darstellen.
Ausgangs-Schaltanschlüsse
Die Objektklasse AV-Ausgangs-Schaltanschluss (AvOutputSwitchPort) leitet ihr grundlegendes Verhalten aus der Klasse AV-Quellenanschluss ab und erweitert dieses Verhalten durch Zulassen einer „Eingangs"-AV-Primitivschaltung, die den internen Koppelfeldweg zu dem entsprechenden Eingangsanschluss darstellt.
Audio-/Video-Anschlüsse im Allgemeinen
Die Objektklasse AV-Anschluss (AvPort) ist eine abstrakte Klasse, die alle Anschlusstypen darstellt. Tatsächlich ist die Klasse AV-Anschluss die Elternklasse sowohl des AV-Quellenanschlusses als auch der AV-Senkenanschlüsse.
Audio-/Video-Primitivschaltung
Ein AV-Primitivschaltungsobjekt (AvPrimitiveCircuit) stellt eine statische oder dynamische Punkt-zu-Punkt-Verbindung in der realen Welt dar, über die sich AV-Signale (Primitiv-AV-Streams) bewegen. Eine AV-Primitivschaltung kann andere AV-Primitivschaltungen in Serie enthalten, um die übergeordnete AV-Primitivschaltung zu bewirken. Es ist vorgesehen, dass dynamische Verbindungen entweder physikalischer Natur oder als Software als AV-Primitivschaltungen gestaltet werden können. Des Weiteren wird bei dem ausgewählten HCS-AV-Netzwerkmodell einem Koppelfeld die Zuständigkeit gegeben, auf Anforderung eine AV-Primitivschaltung dynamisch zu „erzeugen". Letzten Endes verhält sich eine AV-Primitivschaltung, wenn sie einmal erzeugt worden ist, entweder durch Festverdrahtung oder dynamisch, durch Schaltung, Routing usw., auf dieselbe Weise wie jede andere AV-Primitivschaltung.
Beispiel: Die AV-Primitivschaltung AD besteht aus den AV-Primitivschaltungen AB, BC und CD. AB und CD sind statische AV-Primitivschaltungen. Sie entsprechen fest verdrahteten Kabelverbindungen, die an Primitiv-AV-Anschlüsse angeschlossen sind. BC ist eine dynamisch erzeugte AV-Primitivschaltung innerhalb eines Koppelfeldes.

BEMERKUNG: Architektonisch können AB und CD entweder einfache direkte Punkt-zu-Punkt-Verbindungen sein, oder sie können dynamische AV-Primitivschaltungen in der gleichen Form wie Schaltung AD enthalten. Die Komplexität einer AV-Primitivschaltung hängt von der Komplexität der Hardware-Konfiguration ab, die sie abbildet. Durch Darstellen der Schaltungsverbindungen auf diese hierarchische Weise kann einer Vielzahl von Hardware-Architekturen Rechnung getragen werden.

Es ist zu beachten, dass AV-Primitivschaltungen immer gerichtet und an einem Ende durch einen Typ eines AV-Anschlusses und an dem anderen durch den anderen Typ eines AV-Anschlusses gebunden sind.
Die Absicht besteht darin, dass die Objektklasse AV-Primitivschaltung in der Lage sein soll, sowohl Hardware- als auch Software-AV-Transporte darzustellen.
Audio-/Video-Koppelfeld
Ein AV-Schaltobjekt (AvSwitch object) stellt das vollständige AV-Koppelfeld innerhalb eines HCS-Systems dar. Die architektonische Absicht ist, dass alle Schaltgeräte (Hardware und Software) zu einer einzelnen Instanz eines AV-Schalters kombiniert werden sollen. Dies umfasst sowohl implementierte mechanische als auch Software-Lösungen (oder beides). Dies vereinfacht die Verwendung des Koppelfeldes durch andere AV-Komponenten. Die durch einen AV-Schalter dargestellte Abstraktion ist eine zweidimensionale dünnbesetzte Matrix, die in eine Dimension eingibt und in die andere ausgibt.
Auf Aufforderung versucht ein AV-Schalter, eine dynamische AV-Primitivschaltung zwischen dem vorgegebenen AV-Eingangs-Schaltanschluss und dem vorgegebenen AV-Ausgangs-Schaltanschluss zu erzeugen. Dies ist unter Umständen nicht immer möglich. Es wird angenommen, dass es mehrere Ausgänge geben kann, die (mit Multicastfunktionalität) mit einem Eingang verbunden sind.
Virtuelle Audio-/Video-Schaltung
Eine virtuelle AV-Schaltung (AvVirtualCircuit) stellt einen temporären Weg im Hinblick auf einen Satz (1 oder mehr) parallele AV-Primitivschaltungen dar, über die eine AV-Streaminstanz transportiert wird. Genauer gesagt, eine virtuelle AV-Schaltung stellt die Verbindung zwischen einem vollständigen AV-Quellenanschluss und genau einem vollständigen AV-Senkenanschluss mit dem Zweck dar, den vollständigen AV-Stream zu übermitteln, der erzeugt wird. Es ist zu berücksichtigen, dass mehrere virtuelle AV-Schaltungen erforderlich sein können, nur um alle gewünschten AV-Komponentensignale eines AV-Streams zu ihren Zieladressen zu leiten. Es kann wirklich getrennte Zielvorrichtungen geben (z. B. Audio gegenüber Video). Mit anderen Worten, nur weil ein einzelner AV-Komponentenstream von einem AV-Quellenanschluss erzeugt wird, bedeutet dies nicht, dass alle seine AV-Komponentensignale für dasselbe Ausgabegerät und damit für denselben AV-Quellenanschluss bestimmt sind.
Ein AV-Stream wird über eine Mehrwegeverbindung an mehr als einen AV-Quellenanschluss über mehrere virtuelle AV-Schaltungen geleitet.
Aufgrund der hierarchischen Beschaffenheit von AV-Primitivschaltungen stellen virtuelle AV-Schaltungen alle Verbindungen dar, über die die tatsächlichen AV-Signale geleitet werden, und sind mit ihnen verknüpft. Mit anderen Worten, im Hinblick auf AV-Primitivschaltungen stellt eine virtuelle AV-Schaltung die zweidimensionale Matrix von AV-Primitivschaltungen dar, die erforderlich ist, um einen AV-Stream (oder einen Teil davon) von einem AV-Quellenanschluss zu einem AV-Senkenanschluss zu transportieren.
Um den obigen RGB-AV-Stream als Beispiel zu verwenden:
Audio-/Videoprogramm-Player und -Recorder
Objekte, die der Klasse AV-Programm-Player/-Recorder (AvProgramPlayerRecorder) angehören, stellen die „Vorrichtungen", sowohl physikalisch als auch als Software, dar, die die Quelle aller AV-Signale und folglich von AV-Streams innerhalb des HCS-AV-Teilsystems sind. Des Weiteren sind einige Typen von AV-Programm-Playern/-Recordern in der Lage, den Inhalt von AV-Streams (AV-Signale usw...) für einen späteren Zugriff zu speichern. AV-Programm-Player/-Recorder fassen AV-Quellen-/-Senkenanschlüsse, die die Einbeziehung dieser Vorrichtungen in das AV-Netzwerk ermöglichen, zusammen. Logisch gesehen werten AV-Programm-Player/-Recorder entweder den Inhalt von AV-Programmen (AvPrograms) aus und/oder erzeugen AV-Programme beim „Aufzeichnen". Architektonisch können AV-Programm-Player/-Recorder beliebig komplex in ihrer Implementierung sein und brauchen keine physikalische Hardware darzustellen.
Einer der wichtigen Aspekte von AV-Programm-Playern/-Recordern ist, dass sie wissen, welche Typen von AV-Programmen sie auswerten können.
Einige Typen von AV-Programm-Playern/-Recordern behandeln stets ein festgelegtes AV-Programm, während andere sehr dynamisch sein können (wie diejenigen in Jukeboxen).
Audio-/Video-Programmgestaltung
Eine AV-Programm-Objektinstanz stellt eine bestimmte verwaltbare Einheit von AV-Informationen dar, die durch einen geeigneten Typ eines AV-Programm-Piayers/-Recorders (in Form eines vollständigen AV-Streams) ausgewertet und dargestellt werden kann. Im Allgemeinen enthalten AV-Programme alle Informationen, die erforderlich sind, um einen vollständigen AV-Stream wiederzugeben, der einem AV-Stream ähnlich ist, der eingesetzt hätte werden können, um dieses AV-Programm ursprünglich zu erzeugen. Architektonisch können AV-Programme von sehr einfach bis sehr komplex reichen. Tatsächlich können AV-Programme andere AV-Programme enthalten (selbst beliebig verschachtelte). Mit anderen Worten, es können so einfache Dinge wie eine Live-Rundfunkübertragung oder so komplexe Dinge wie gespeicherte Multimedia-Präsentationen als AV-Programme dargestellt werden.
Alle AV-Programme enthalten zwei unterschiedliche Typen von Attributen: beschreibende und inhaltliche. Die Verfahren, die eingesetzt werden, um AV-Programminhalt darzustellen und darauf zuzugreifen, sind für die verschiedenen Arten von AV-Programmen kennzeichnend und werden als solche nicht weiterführend in dieser Veröffentlichung erörtert.

BEMERKUNG: Die AV-Programm-Abstraktion macht, wie bei den meisten anderen Aspekten des HCS, reichlich Gebrauch von ASN.1-Objekt-IDs zum Zweck einer hierarchischen Klassifizierung.

Die folgenden architektonischen Attribute sind allen Typen von AV-Programmen gemein und definieren als solche das grundlegende Verhalten für alle AV-Programm-Implementierungen. Diese umfassen: Programmbeschreibung (programDescription), Programmtyp (programType) und Programmposition (programLocation).

Attribut: Programmbeschreibung: Die Programmbeschreibung ist eine kurze, einzeilige Textbeschreibung des Programms.
Attribut: Programmtyp: Das Attribut Programmtyp ist eine ASN.1-Objekt-ID mit einer Präambel vom Typ 1.11, die ein Programm so weit klassifiziert, dass alle anderen Attribute einschließlich Inhalt ausgewertet werden können; wobei spezifische Kenntnis über diesen Programmtyp angenommen wird. Der grundlegende Namensraum des Programmtyps ist wie folgt strukturiert: 1.11.1: Rundfunkprogramm 1.11.2.1: Gespeichertes Programm: Physikalische Einzelzugriff-Medien (z. B. CD, VHS-Band...) 1.11.2.2: Gespeichertes Programm: Vielfachzugriff-Medien (z. B. JPEG-Bild...)

Dies sind die einzig gültigen Präambeln mit dem Wert Programmtyp. AV-Programme vom Typ 1.11.2.1 können nur in einem AV-Programm-Player/-Recorder gleichzeitig verwendet werden, während AV-Programme vom Typ 1.11.2.2 in mehreren AV-Programm-Player/-Recordern gleichzeitig wiedergegeben werden können.

Attribut: Programmposition: Das Attribut Programmposition ist eine ASN.1.-Objekt-ID mit einer Präambel vom Typ 1.6.1, die die exakte Position des AV-Programms kennzeichnet. Die tatsächliche Bedeutung von „Position" hängt von dem spezifischen AV-Programmtyp ab. Dies bedeutet jedoch nicht, dass an dieses Attribut keine architektonischen Anforderungen gestellt werden. Der grundlegende Namensraum der Programmposition ist wie folgt strukturiert: 1.6.1.1: AV-Programmposition: AV-Programm-Player/-Recorder verknüpft. 1.6.1.2: AV-Programmposition: AV-Programm-Player/-Recorder unabhängig.

Dies sind die einzig gültigen Präambeln mit dem Wert Programmposition. Es ist sehr wichtig zu verstehen, dass diese Präambeln unterschiedliche Typen von Positionen, nicht von Programmen klassifizieren. Mit anderen Worten, derselbe Typ eines AV-Programms (z. B. VHS-Band) könnte sich an einer Position befinden, der mit einem AV-Programm-Player/-Recorder verknüpft ist (wie einer Jukebox), oder er könnte unabhängig von einem AV-Programm-Player/-Recorder sein (wie in einem Regal). Der Grund für diese architektonische Unterscheidung zwischen diesen unterschiedlichen Arten von Positionen besteht darin, dass AV-Programme, die mit einem AV-Programm-Player/-Recorder verknüpft sind, wissen, wie sie sich selbst laden können. Ein gutes Beispiel dafür ist eine CD, die sich in einer Jukebox befindet. Ein solches AV-Programm weiß, in welcher Jukebox es sich befindet, und kann die Jukebox anweisen, es in einen geeigneten AV-Programm-Player/-Recorder (ein geeignetes Laufwerk) zu laden.
Audio-Nideo-Programmgestaltungspools
Instanzen der Objektklasse AV-Programmpool (AvProgramPool) stellen eine geordnete Sammlung von AV-Programmen dar. AV-Programmpools sorgen für das Hinzufügen, Entfernen, Suchen, Durchsuchen und indirekt die Präsentation der ihn ihnen enthaltenen AV-Programme. Ein weiterer Aspekt von AV-Programmpools ist, dass, wenn sie (über einen Verweis) andere AV-Programmpools enthalten können, diese „Einschließungs"-Beziehung so implementiert ist, dass sie den Zugriff auf Unter-AV-Programmpools erkennbar macht. Dies ermöglicht das „Zusammenkleben" von mehreren Unterpools, während der Eindruck eines einzigen AV-Programmpools erweckt wird.
Programmatisch und architektonisch sorgen AV-Programmpools für gemeinsamen Zugriff und gemeinsame Verwaltung in einer vernetzten Umgebung. Um dies zu bewirken, werden andere programmatisch wichtige Hilfsobjekte als Teil der AV-Programmpool-Objektfamilie (wie Zugriffscursor und Ähnliches) definiert.
Physikalische Einheiten wie zum Beispiel Jukeboxen und Bilddatenbanken werden durch AV-Programmpools dargestellt.
AV-Raumservice
Die Objektklasse HCS-AV-Raumservice (HcsAVSpatialService) ist eine abstrakte Klasse, von der raum- und AV-bezogene Klassen ihr Verhalten übernehmen. Dies ist gegenwärtig nur ein Platzhalter in der Klassifikationshierarchie.
Audio-/Video-Unterhaltungszentrum
Es wird der Begriff „Unterhaltungszentrum" verwendet, weil er ein gutes intuitives „Gefühl" für das Verhalten dieser Art von Objekt verleiht. Das Gefühl, das der Benutzer zu einem HCS-Unterhaltungszentrum bekommen sollte, ist das einer Sammel- oder Anlaufstelle, bei der AV-Quellen ausgewählt und zu Ausgängen wie zum Beispiel Lautsprechern, Anzeigen und Recordern geleitet werden können.
HCS-Unterhaltungszentren kennen ihre Haupt-AV-Ausgänge und können diesen automatisch benutzerdefinierte AV-Programmierung über einen „Ausgleichs"-Algorithmus bieten. Über diesen automatischen Betriebsmodus hinaus ermöglichen HCS-Unterhaltungszentren außerdem das Stattfinden von komplexem Routing, sogar außer halb ihres natürlichen Bereichs (Raums). Der grundlegende Ansatz des UI-Modells des HCS-Unterhaltungszentrums ist: „Einfaches ist leicht umzusetzen, aber Kompliziertes ist möglich."
Ein Ziel ist, dass es nur eine Art der Implementierung des HCS-Unterhaltungszentrums geben soll.
Im Hinblick auf das Programm manipuliert die Klasse HCS-Unterhaltungszentrum die zusammengefassten Elemente, aus denen eine Benutzeranforderung besteht – und berücksichtigt dabei, dass ein Benutzer seine Meinung ändern und Dinge in willkürlicher Reihenfolge tun kann. Es ist wichtig zu verstehen, dass dieses „Zusammenfassen der Benutzerabsicht" auf einer sehr abstrakten Ebene geschieht.
HCS-Unterhaltungszentren stellen einen UI-Rahmen bereit, durch den andere AV-Objekte ihre UI-Komponenten darstellen. Zum Beispiel würde sich ein AV-Programm-Player/-Recorder selbst durch HCS-Unterhaltungszentren darstellen und durch sie mit dem Benutzer interagieren. Es muss darüber hinaus berücksichtigt werden, dass HCS-Unterhaltungszentren selbst ihre UIs letzten Endes durch verschiedene Arten von HCS-Benutzerkontrollpunkte darstellen und als solche ihr Verhalten auf diese verschiedenen Umgebungen zuschneiden.
Zurück zum Funktionalitätsmodell
Zu diesem Zeitpunkt wird der Leser angeregt, die Objektmodell-Definitionen nochmals durchzusehen, da es fast unmerkliche gegenseitige Beziehungen zwischen den Klassen in diesem Objektmodell gibt.

Wir werfen nun einen Blick auf das AV-Funktionalitätsmodell und bilden die verschiedenen Objektklassen auf die Funktionalitätsschicht, die sie implementieren, ab.

Schicht	Objekte
Serviceschicht	HCS-AV-Raumservices, HCS-AV-Sammlungen und HCS-Unterhaltungszentren
Verwaltungsschicht	AV-Signale, AV-Streams, AV-Programme, AV-Programmpools und AV-Programm-Player/-Recorder
Vermittlungsschicht	Virtuelle AV-Schaltungen, AV-Anschlüsse, AV-Schalter und AV-Primitivschaltungen

Jede dieser Schichten wird unten erörtert, angefangen bei der Vermittlungsschicht bis hinauf zu der Serviceschicht. Es ist wichtig zu verstehen, dass die durch dieses Modell angegebene Schichtung nicht bedeutet, dass die untergeordneten Objektarten (wie zum Beispiel auf der Vermittlungsschicht) keine Kenntnis über die übergeordneten Objekte haben – es handelt sich hier nicht um ein geschichtetes Kommunikationsreferenzmodell.
Vermittlungsschicht
Die Objekte, die die Vermittlungs-Funktionalitätsschicht implementieren, stellen das „Leitungssystem" des AV-Systems dar. Insbesondere die Quellen, Schaltungen (dynamisch und statisch), Strecken und Zieladressen aller AV-Informationen. Man kann die Objekte auf dieser Ebene auch als Informationen sehen, die sie enthalten. Zu einem beliebigen festgelegten Zeitpunkt verkörpern die Objekte auf dieser Ebene eine schematische Darstellung der Vernetzung zwischen allen AV-Komponenten in einer HCS-Installation.
Die Veröffentlichung mit dem Titel „HCS AV Network Components Design" definiert jede Objektklasse dieser Schicht ausführlich.
Verwaltungsschicht
Die Objekte, die die Verwaltungs-Funktionalitätsschicht implementieren, sind für das Verwalten aller Vorrichtungen, Prozesse und Informationen aus AV-Sicht zuständig. Dies bezieht Geräte-„Treiber” in Form von AV-Programm-Playern/-Recordern und Live- und gespeicherte Informationen durch die Implementierung von AV-Programmen, AV-Signalen, AV-Streams und AV-Programmpools ein.
Hierbei handelt es sich um die Schicht, die die meiste Arbeit in Hinblick auf das aktive Ausführen von Benutzeranforderungen verrichtet.
Siehe die Veröffentlichung mit dem Titel „HCS AV Management Components Design" für eine vollständige Definition der Objekte auf dieser Ebene.
Serviceschicht
Die Objekte, die diese Funktionalitätsschicht implementieren, sind für das Abbilden von verschiedenen Komponenten der Verwaltungsebene auf einen natürlichen UI-Rahmen für den Benutzer zuständig. Üblicherweise wird ein auf den Raum konzentrierter Ansatz wie der des HCS-Unterhaltungszentrums gewählt. Wenn andere, nicht auf den Raum konzentrierte Modelle benötigt werden, können andere Typen von Komponenten auf dieser Ebene eingeführt werden, ohne Komponenten auf anderen Ebenen zu beeinträchtigen.
Siehe die Veröffentlichung mit dem Titel „HCS AV Service Components Design" für eine vollständige Definition der Objekte auf dieser Ebene.
ANHANG 2
Es gibt zwei grundlegende Typen von AV-Programmen, die einzelne Rundfunkprogramme verkörpern. hcsBrdCstAudioAvPrg und hcsBrdCstVideoAvPrg. Diese Typen sind Unterklassen beider hcsBrdCstAvPrg und kennzeichnen folglich AV-Programmtypen (hcsAvProgTypeld). Diese Typen werden (gemeinsam) eingesetzt, um Typen von AV-Rundfunkprogrammgestaltung darzustellen.
Zum Darstellen von Gruppen verwandter Kanäle oder Sendestationen werden zwei oder mehr Typen von AV-Programmen, hcsBrdCstAudioGrpAvPrg und hcsBrdCstVideoGrpAvPrg definiert. Diese werden eingesetzt, um Sätze von „Kanälen" zu einem übergeordneten Programm zusammenzufassen, so wie es eine CD für CD-Tracks ausführt. Dies ermöglicht einer verwandten Gruppe von Kanälen, als Satz konfiguriert zu werden (z. B. alle Kabel-TV-Kanäle) und als Ganzes „wiedergegeben" zu werden. Dieser Ansatz ermöglicht auf der Player-/Recorder-MCI-Ebene das Schalten zwischen Kanälen genauso, wie heute zwischen Tracks auf einer CD geschaltet wird.
Positions-IDs von Medienmanager-AV-Programmen haben die folgende Form:
hcsAvPrglslnMediaMgr. <mmld>. <Position im mm>.
Das mmld-Feld ist eine eindeutige Nummer, die eine Instanz eines Medienmanagers innerhalb eines Systems darstellt. Diese Nummer wird von dem zentralen Medienmanager (nur von einem pro Installation) zum Weiterleiten von Programm-Ladeanforderungen an den geeigneten Medienmanager verwendet. Das tatsächliche Format des Feldes <Position im mm> ist für den tatsächlichen Typ des AV-Programms spezifisch. Für eine typische Jukebox (ein Art Medienmanager) ist dies eine Nummer, die einem Schlitz in der Jukebox zugeordnet ist. Die Positions-ID eines AV-Programms ist eindeutig – eine Instanz eines AV-Programms hat eine eindeutige Position in der Raum-Zeit (SpaceTime).
Format der Positions-ID: HcsBrdCstAudioGrpAvPrg
Das Feld <Position im mm> für hcsBrdCstAudoGrpAvPrg-AV-Programme weist die folgenden Werte auf:
0 – Mittelwellenfunk-Signalgruppe
1 – UKW-Funk-Signalgruppe
2 – DMX-Audio-Signalgruppe

BEMERKUNG: Alle Unterprogramm sind vom selben Typ.

Format der Positions-ID: hcsBrdCstVideoGrpAvPrg
Das Feld <Position im mm> für hcsBrdCstVideoGrpAvPrg-AV-Programme weist die folgenden Werte auf:
0 – Kabelfernsehen-Signalgruppe
1 – Antennen-Signalgruppe
2 – DSS-Signalgruppe

BEMERKUNG: Alle Unterprogramm sind vom selben Typ.

Format der Positions-ID: HcsBrdCstAudioAvPrg

Das Feld <Position im mm> für hcsBrdCstAudoAvPrg-AV-Programme hat das folgende Format:
<Typ>. <Freq>[.<Zeit>]
wobei gilt:

<Typ>:	0 – Mittelwellenfunkstation
	1 – UKW-Funkstation
	2 – DMX-Audiostation
<Freq>:	Frequenz der Station in Kilohertz
<Zeit>:	Optional. Gibt einen Zeitbereich für das Programm an. Falls
	nicht vorhanden, sollte „andauernd" angenommen werden.

Format der Positions-ID: hcsBrdCstVideoAvPrg

Das Feld <Position im mm> für hcsBrdCstVideoAvPrg-AV-Programme hat das folgende Format:
<Typ>. <Kanal> [.<Zeit>]
wobei gilt:

<Typ>:	0 – Kabel-TV-Kanal
	1 – Antennen-TV-Kanal
	2 – DSS-Kanal
<Kanal>:	Kanalnummer
<Zeit>:	Optional. Gibt einen Zeitbereich für das Programm an. Falls
	nicht vorhanden, sollte „andauernd" angenommen werden.

ANHANG 3
HCS-Protokollunterstützung
Alle Protokollsätze werden unter Verwendung einer ASN.1-Objekt-ID klassifiziert.
Standard-Protokollsatz-Klassifizierung vom Typ ASN.1:
1.x – Alle Protokollsätze
1.x.0 – Unkritisch
1.x.0.0 – Protokollausgabe
1.x.0.1 – Fortschritt
1.x.1 – Fehler
1.x.2 – Warnhinweis
Protokollsätze bestehen aus vier Informationsfeldern: Typ, Zeit, Erzeuger, Informationen. Typ und Zeit sind ASN.1-IDs, während der Erzeuger entweder eine ASN.1-HCS-Ressourceninstanz-ID oder eine Textfolge sein kann. Das Informationsfeld ist der eigentliche durch die Protokollkomponente erzeugte Text.
Es gibt verschiedene Komponenten in dem System, die zuständig für das Zusammenfassen, Speichern und mögliche Weiterleiten von Protokollsätzen sind. Alle Formen dieser Komponente werden durch die Klasse HCS-Protokolleinrichtung (HcsLogFacility) gebildet.
Klasse HCS-Protokolleinrichtung
Die Klasse HCS-Protokolleinrichtung ist eine Ableitung der HCS-Ressource (HcsResource), deren Zweck es ist, Speicherung und Weiterleiten auf verschiedenen Ebenen in dem System bereitzustellen. Es gibt derzeit zwei Implementierungen: die lokale Protokolleinrichtung (Local Log Facility) und die zentrale Protokolleinrichtung (Central Log Facility). Die Schnittstelle der HCS-Protokolleinrichtung ist:
Die lokale Protokolleinrichtung
Es ist in jedem Knoten in dem System eine lokale Protokolleinrichtung (Local Log Facility – LLF) vorhanden. Der Zweck dieser Implementierung einer HCS-Protokolleinrichtung besteht darin, alle Protokollsätze von verschiedenen HCS-Komponenten an diesem Knoten entgegenzunehmen und sie in einem großen Ringspeicher auf der Platte zwischenzuspeichern, bis sie an die zentrale Protokolleinrichtung (Central Log Facility – CLF) geliefert werden können. Es ist die Absicht, dass ein Knoten eine Weile lang fortbestehen kann, falls die CLF nicht erreichbar ist. Einer der Konfigurationsparameter, die an jede lokale HCS-Protokolleinrichtungs-Instanz weitergegeben werden, ist der Ressourcenname der HCS-Protokolleinrichtung, durch die diese Instanz ihre Protokollsätze weiterleiten soll. Die derzeitige Ansicht ist, dass dies der Name der CLF ist, aber dies ist keine architektonische Anforderung. Mit anderen Worten, es könnten Zwischenebenen von HCS-Protokolleinrichtungen in dem System positioniert werden. Tatsächlich könnte eine LLF so konfiguriert werden, dass sie ihre Protokollsätze an eine weitere LLF weiterleitet. Schließlich ist eine HCS-Protokolleinrichtung eine HCS-Protokolleinrichtung.
Die zentrale Protokolleinrichtung
Es gibt eine Instanz der CLF-Instanz (CLF – Central Log Facility – zentrale Protokolleinrichtung) im gesamten System. Der Zweck dieser Implementierung der HCS-Protokolleinrichtung besteht darin, alle Protokollsätze von verschiedenen HCS-Komponenten innerhalb des gesamten Systems entgegenzunehmen und für die endgültige Speicherung dieser Informationen zu sorgen. Die Absicht ist, dass diese Einrichtung für die langfristige Offline-Archivierung des gesamten HCS-Systemprotokolls sorgt. Über diese Funktion hinaus sorgt sie außerdem für die Online-Anzeige eines Teils dieses Protokolls.
Wie Protokollsätze geschrieben werden
Die Frage lautet also: Wie protokollieren HCS-Komponenten ihre Informationen? Um einen standardisierten und sicheren Zugriff auf die HCS-Protokolleinrichtungen bereitzustellen, wird eine Klassenfamilie bereitgestellt. Die Familie basiert auf einer Klasse mit der Bezeichnung HCS-Protokollanschluss (HcsLgPort). Diese Klasse implementiert das gemeinsame Verhalten aller Typen von Protokollanschlüssen und ist für sich allein funktionsfähig.
Von dem HCS-Protokollanschluss sind die Klassen HCS-Ressourcen-Protokollanschluss (HcsResourceLogPort) und HCS-Protokolleinrichtungs-Anschluss (HcsLogFacilityPort) abgeleitet. Der HCS-Ressourcen-Protokollanschluss stellt einfache Unterstützung für den Ressourcen-Entwickler bereit, während der HCS-Protokolleinrichtungs-Anschluss den direkten Zugriff auf HCS-Protokolleinrichtungen bereitstellt. Im Allgemeinen wird der erste durch Ressourcen-Ableitungen genutzt, während der zweite durch Ressourcen-Server und Systemkomponenten genutzt wird.
Auswirkungen auf die Schnittstelle der HCS-Ressourcen-Implementierung (HcsResourcelmp)

HcsResourcelmp::putLogRecord-Implementierung: behält eine interne HCS-Protokolleinrichtungs-Anschlussinstanz, die zum Durchleiten von Protokollsätzen eingesetzt wird. Bevor ein Protokollsatz tatsächlich weitergeleitet wird, stellt die HCS-Ressourcen-Implementierung sicher, dass diesem Anschluss eine HCS-Protokolleinrichtung zugewiesen worden ist. Ist dies nicht der Fall, wird ein Versuch unternommen, die lokale HCS-Protokolleinrichtung für diesen Knoten über das HcsResrcBuslf::locateLocalResourceByld-Verfahren zu orten (neu). In jedem Fall wird der Protokollsatz über den HCS-Protokolleinrichtungs-Anschluss der Ressourceninstanz geschrieben.
Neu: Die HCS-Ressourcen-Schnittstelle definiert, und die HCS-Ressourcen-Implementierung implementiert zwei Verfahren: HRESULT enableLogging ([in, string]char* forLogRecClassPtr); HRESULT disableLogging ([in, string]char* forLogRecClassPtr);

Diese werden durch Support eingesetzt, um die Protokollierung dynamisch innerhalb von Instanzen von HCS-Ressourcen zu aktivieren und zu deaktivieren.
Die Klasse HCS-Protokolleinrichtung und HCS-Protokolleinrichtungs-Anschlüsse
Es ist zu beachten, dass auf jede HCS-Protokolleinrichtung durch einen HCS-Protokolleinrichtungs-Anschluss verwiesen werden kann. Dies bedeutet, dass einige Komponenten sich unter Umständen direkt an die CLF anschließen möchten. Ein gutes Beispiel hierfür ist möglicherweise der Ressourcen-Busmanager (RBMGR.EXE).

Claims

Audio-/visuelles System, das umfasst: wenigstens eine Ausgangskomponente (1101), die wenigstens einen Quellen-Anschluss für jeden Typ Ausgangssignal, das von der wenigstens einer Ausgangskomponente ausgegeben wird, und wenigstens ein Quellen-Anschluss-Objekt für jeden von dem wenigstens einen Quellen-Anschluss hat; und wenigstens eine Eingangskomponente (1102, 1103), die wenigstens einen Senken-Anschluss (sink Port) für jeden Typ Eingangssignal, das in die wenigstens eine Eingangskomponente eingegeben wird, und wenigstens ein Senken-Anschluss-Objekt für jeden wenigstens einen Senken-Anschluss hat, wobei jeder wenigstens eine Quellen-Anschluss der wenigstens einen Ausgangskomponente mit dem wenigstens einen Senken-Anschluss der wenigstens einen Eingangskomponente über wenigstens einen Primitivschaltungsweg (primitive circuit path) verbunden werden kann, wobei der Primitivschaltungsweg eine virtuelle Schaltung umfasst.
Audio-/visuelles System nach Anspruch 1, das des Weiteren wenigstens ein Primitivschaltungs-Objekt für jeden der wenigstens einen Primitivschaltungswege mit einem Signal enthält, das wenigstens (A) von einem Quellen-Anschluss ausgeht, oder (B) an einem Senken-Anschluss endet.
Audio-/visuelles System nach Anspruch 1, wobei der wenigstens eine Primitivschaltungsweg zwischen dem wenigstens einem Quellen-Anschluss und dem wenigstens einem Senken-Anschluss wenigstens ein statischer Weg (static path) oder ein dynamischer Weg (dynamic path) ist.
Audio-/visuelles System nach Anspruch 1, das des Weiteren wenigstens einen Schaltmechanismus enthält, der wenigstens einen Eingangs-Schaltanschluss und wenigstens einen Ausgangs-Schaltanschluss aufweist, wobei ein Schaltmechanismus des wenigstens einen Schaltmechanismus so eingerichtet ist, dass er ermöglicht, dass der wenigstens eine Eingangs-Schaltanschluss, der mit dem Schaltmechanismus zusam menhängt, mit dem wenigstens einen Ausgangs-Schaltanschluss verbunden wird, der mit dem Schaltmechanismus zusammenhängt, um so wenigstens einen dynamischen Weg zwischen dem wenigstens einem Eingangs-Schaltanschluss und dem wenigstens einen Ausgangs-Schaltanschluss herzustellen.
Audio-/visuelles System nach Anspruch 1, wobei das wenigstens eine Quellen-Anschluss-Objekt und das wenigstens eine Senken-Anschluss-Objekt von einer Anschluss-Objektklasse hergeleitet werden und Mitgliedsfunktionen der Anschluss-Objektklasse wenigstens eine Funktion, die so eingerichtet ist, dass sie einen Bezug zu dem Eigner-Objekt wenigstens einer Instanz zu der Anschluss-Objektklasse zurückführt, eine Funktion, die so eingerichtet ist, dass sie eine Anzeige dahingehend zurückführt, ob wenigstens eine Instanz der Anschluss-Objektklasse ein vollständiger Anschluss ist, eine Funktion, die so eingerichtet ist, dass sie eine Anzeige dahingehend zurückführt, ob wenigstens eine Instanz der Anschluss-Objektklasse ein Primitiv-Anschluss ist, eine Funktion, die so eingerichtet ist, dass sie einen Bezug zu dem Eltern-Anschluss wenigstens einer Instanz der Anschluss-Objektklasse zurückführt, eine Funktion, die so eingerichtet ist, dass sie die Anzahl von Kind-Anschlüssen wenigstens einer Instanz der Anschluss-Objektklasse oder eine Funktion einschließen, die so eingerichtet ist, dass sie einen Bezug zu einem Kind-Anschluss für wenigstens eine Instanz der Anschluss-Objektklasse zurückführt.
Audio-/visuelles System nach Anspruch 1, wobei ein Verfahren auf Wire-Protocol-Basis eingesetzt wird, das die Semantik der wenigstens einen Ausgangskomponente und der wenigstens einen Eingangskomponente unterstützt.
Audio-/visuelles System nach Anspruch 1, das des Weiteren einen Schaltmechanismus enthält, der so eingerichtet ist, dass er den wenigstens einen Quellen-Anschluss der wenigstens einen Ausgangskomponente mit dem wenigstens einen Senken-Anschluss der wenigstens einen Eingangskomponente verbindet, und wobei das Verbinden durch den Schaltmechanismus dynamisches Zuweisen einer Strom-Transportressource einschließt.
Audio-/visuelles System nach Anspruch 7, wobei der Schaltmechanismus ein hierarchisch verschachtelter Schaltmechanismus ist.
Audio-/visuelles System nach Anspruch 1, wobei die wenigstens eine Ausgangskomponente wenigstens (A) eine Anzeigekomponente oder (B) eine Lautsprechersystem-Komponente enthält, wobei ein Anzeige-Objekt eine Anzeigekomponente darstellt und ein Lautsprechersystem-Objekt eine Lautsprechersystem-Komponente darstellt.
Audio-/visuelles System nach Anspruch 9, wobei eine Lautsprechersystem-Komponente einen Senken-Anschluss enthält und eine Anzeige-Komponente einen Senken-Anschluss enthält.
Audio-/visuelles System nach Anspruch 1, das des Weiteren umfasst: wenigstens eine Unterhaltungs-Session; und wenigstens eine Player-/Recorder-Komponente, die mit jeder Unterhaltungs-Session zusammenhängt und wenigstens eine Ausgangskomponente enthält, wobei eine Player-/Recorder-Komponente ein Typ Quellen-Objekt ist.
Audio-/visuelles System nach Anspruch 11, wobei jede Unterhaltungs-Session einen Prozess zum Zuweisen eines Programms zu der Unterhaltungs-Session einschließt und das System so eingerichtet ist, dass es: eine Funktion zum Auswählen eines audiovisuellen Programmeintrags aufruft, um so einen Bezug zu dem audiovisuellen Programmeintrag zurückzuführen, und eine eingestellte aktuelle Programmfunktion des Unterhaltungs-Session-Objektes aufruft und den Bezug zu dem audiovisuellen Programmeintrag weiterleitet.
Audio-/visuelles System nach Anspruch 11, wobei jede Unterhaltungs-Session einen Prozess zum Auswählen eines Programms für die Unterhaltungs-Session einschließt und das System so eingerichtet ist, dass: eine Benutzerschnittstelle angezeigt wird, die es einem Benutzer gestattet, durch die Programme zu blättern, die mit einer Programmangebot-Datenstruktur zusammenhängen; ein Programm über die Benutzerschnittstelle ausgewählt wird; und ein Rückführbezug zu einem Bezug auf ein Programmobjekt festgelegt wird, das mit dem ausgewählten Programm zusammenhängt.
Audio-/visuelles System nach Anspruch 11, wobei jede Unterhaltungs-Session einen Prozess zum Auswählen eines Programms für die Unterhaltungs-Session einschließt, und das System so eingerichtet ist, dass ein durch die Unterhaltungs-Session überwachtes Programm eingegeben wird; und ein auf das eingegebene Programm bezogenes Programmobjekt durch die Unterhaltungs-Session automatisch ausgewählt wird.
Audio-/visuelles System nach Anspruch 11, wobei ein Raum-Objekt mit jeder Unterhaltungs-Session zusammenhängt und ihren Raum bezeichnet und ein Player-/Recorder-Objekt mit jeder Player-/Recorder-Komponente zusammenhängt.
Audio-/visuelles System nach Anspruch 11, wobei eine Unterhaltungs-Session der wenigstens einen Unterhaltungs-Session ein Verhalten bereitstellt, das es gestattet, ein Audio-/visuelles Programm einer Player-/Recorder-Komponente zuzuweisen, und wobei, wenn ein Audio-/visuelles Programm einer Unterhaltungs-Session zugewiesen wird, die Unterhaltungs-Session so eingerichtet ist, dass sie das audiovisuelle Programm in einen Player-/Recorder lädt, und so eingerichtet ist, dass sie veranlasst, dass das Programm durch den Player-/Recorder abgespielt wird, und so eingerichtet ist, dass sie wenigstens ein Ausgangssignal der Player-/Recorder-Komponente zu wenigstens einer damit zusammenhängenden Ausgangskomponente leitet.
Audio-/visuelles System nach Anspruch 11, wobei eine Unterhaltungs-Session so eingerichtet ist, dass sie eine Benutzerschnittstellenkomponente zum Steuern wenigstens einer Benutzerschnittstelle wenigstens (A) wenigstens einer Eingangskomponente oder (B) der wenigstens einer Ausgangskomponente bereitstellt, die mit der Unterhaltungs-Session zusammenhängt.
Audio-/visuelles System nach Anspruch 11, das des Weiteren umfasst: eine Programmauswahl-Datenstruktur, die hierarchisch einen Satz audiovisueller Programmeinträge darstellt, wobei jeder audiovisuelle Programmeintrag eine entsprechende Programmangebot-Datenstruktur hat.
Audio-/visuelles System nach Anspruch 18, wobei die Programmangebot-Datenstruktur wenigstens (A) ein Verhalten zum Durchsuchen der Hierarchie der audiovisuellen Programmeinträge bereitstellt, die durch die Programmangebot-Datenstruktur dargestellt werden, (B) zulässt, dass eine Player-/Recorder-Komponente einem audiovisuellen Programmeintrag der Programmangebote-Datenstruktur zugewiesen wird, (C) ein Verhalten bereitstellt, das das Laden eines audiovisuellen Programmeintrags einer Player-/Recorder-Komponente entspricht, oder (D) zulässt, dass eine Unterhaltungs-Session durch einen Session-Manager erzeugt wird.
Audio-/visuelles System nach Anspruch 1, das des Weiteren umfasst: dass wenigstens ein Medien-Manager-Objekt so eingerichtet ist, dass es Medien an seinem Standort verwaltet, und wenigstens ein durch das wenigstens eine Medien-Manager-Objekt bestimmtes geeignetes Objekt für die durch das wenigstens eine Medien-Manager-Objekt verwalteten Medien bereitstellt.
Audio-/visuelles System nach Anspruch 20, wobei ein Medien-Manager-Objekt eine Programmladefunktion einschließt, die einem audiovisuellen Programmeintrag zugeleitet wird und die so eingerichtet ist, dass sie wenigstens ein geeignetes Objekt mit dem Programm zurückführt, das dem geladenen audiovisuellen Programmeintrag entspricht.
Verfahren zum Einrichten eines Weges zwischen einer Ausgangskomponente und einer Eingangskomponente in einem Audio-/visuellen System, das wenigstens eine Ausgangskomponente (1101), die wenigstens einen Quellen-Anschluss, der so eingerichtet ist, dass er jeden Typ Ausgangssignal unterstützt, das von der wenigstens einen Ausgangskomponente ausgegeben wird, und wenigstens ein Primitiv-Quellen-Anschluss-Objekt (primitive source Port object) für jeden wenigstens einen Quellen-Anschluss hat; sowie wenigstens eine Eingangskomponente (1102, 1103) umfasst, die wenigstens einen Senken-Anschluss (sink port), der so eingerichtet ist, dass er jeden Typ Eingangssignal unterstützt, das in die wenigstens einen Eingangskomponente eingegeben wird, sowie ein Primitiv-Senken-Anschluss-Objekt (primitive sink Port object) für jeden Senken-Anschluss hat, wobei jeder wenigstens eine Quellen-Anschluss der wenigstens einen Ausgangskomponente mit dem wenigstens einen Senken-Anschluss der wenigstens einen Eingangs-Komponente über wenigstens einen Primi tiv-Schaltungsweg (primitive circuit path) verbunden werden kann, wobei das Verfahren umfasst: Instantiieren eines virtuellen Schaltungsobjektes, das einen Weg zwischen dem Quellen-Anschluss, der dem vollständigen Quellen-Anschluss-Objekt entspricht, und dem Senken-Anschluss einrichtet, der dem vollständigen Senken-Anschluss-Objekt entspricht.
Verfahren nach Anspruch 22, das des Weiteren einschließt: Einrichten eines Primitiv-Schaltungsweges unter Verwendung eines Ausgangs-Objektes, das die Ausgangs-Komponente darstellt, und eines Eingangs-Objektes, das die Eingangs-Komponente darstellt.
Verfahren nach Anspruch 22, das des Weiteren einschließt: Anfordern, dass das Ausgangs-Objekt einen Bezug zu einem vollständigen Quellen-Anschluss-Objekt bereitstellt; Anfordern, dass das vollständige Quellen-Anschluss-Objekt einen Bezug zu seinem entsprechenden vollständigen Stream-Objekt bereitstellt; und Anfordern, dass das Eingangs-Objekt einen Bezug zu seinem entsprechenden vollständigen Senken-Anschluss-Objekt bereitstellt.
Verfahren nach Anspruch 22, wobei der Senken-Anschluss und der Quellen-Anschluss in dem gleichen Anschluss enthalten sind.
Verfahren nach Anspruch 22, wobei das Instantiieren Hosting des virtuellen Schaltungsobjektes durch den Quellen-Anschluss einschließt.
Verfahren nach Anspruch 22, wobei das Verfahren des Weiteren einschließt: Aufrufen einer Funktion zum Erzeugen einer virtuellen Schaltung, wobei das Aufrufen ein Leiten eines Bezugs zu dem Senken-Anschluss-Objekt einschließt; in Reaktion auf das Aufrufen Konstruieren eines neuen virtuellen Schaltungsobjektes, wobei das Konstruieren Leiten eines Bezuges zu dem Quellen-Anschluss-Objekt und eines Bezuges zu dem Senken-Anschluss-Objekt zu einer Konstruktionseinrichtung einschließt; und Hinzufügen des neuen virtuellen Schaltungsobjektes zu einer Liste virtueller Schaltungen, die mit dem Quellen-Anschluss-Objekt zusammenhängen.
Verfahren nach einem der Ansprüche 22 bis 27, wobei das Verfahren des Weiteren umfasst: Verbinden wenigstens eines Quellen-Anschlusses wenigstens einer Ausgangskomponente mit wenigstens einem Senken-Anschluss wenigstens einer Eingangskomponente über wenigstens einen Primitiv-Schaltungsweg; wobei jede der wenigstens einen Ausgangskomponente wenigstens einen Quellen-Anschluss für jeden Typ Ausgangssignal, das von der wenigstens einen Ausgangs-Komponente ausgegeben wird, und wenigstens ein Quellen-Anschluss-Objekt für jeden von dem wenigstens einen Quellen-Anschluss enthält, und wobei jede der wenigstens einen Eingangskomponente wenigstens einen Senken-Anschluss für jeden Typ Eingangssignal, das in die wenigstens einen Eingangskomponente eingegeben wird, und wenigstens ein Senken-Anschluss-Objekt für jeden von dem wenigstens einen Senken-Anschluss enthält.