DE69507051T2

DE69507051T2 - Bildinformationskommunikationsverfahren zwischen mehrfachprotokoll-bildaufnahmevorrichtungen

Info

Publication number: DE69507051T2
Application number: DE69507051T
Authority: DE
Inventors: Kent J. Saint Paul Mn 55133-3427 Sieffert
Original assignee: Minnesota Mining and Manufacturing Co
Current assignee: Carestream Health Inc
Priority date: 1994-11-22
Filing date: 1995-10-10
Publication date: 1999-05-12
Anticipated expiration: 2015-10-11
Also published as: AU3896295A; JP3695758B2; ATE175286T1; DE69507051D1; EP0793828B1; JPH10509852A; EP0793828A1; WO1996016373A1; CA2203898A1; US5630101A

Description

System zur Bildinformationskommunikation zwischen Mehrfachprotokoll-Bildverarbeitungsvorrichtungen

Technisches Gebiet der Erfindung

Die Erfindung betrifft Bildverarbeitungssysteme und insbesondere Systeme zur Übermittlung von Bildinformationen zwischen einer Eingangsabbildungsvorrichtung und einer Ausgangsabbildungsvorrichtung in einem Bildverarbeitungssystem.

Diskussion der verwandten Technik

Ein Bildverarbeitungssystem weist typischerweise eine Eingangsabbildungsvorrichtung, die Bildinformationen erzeugt, und eine Ausgangsabbildungsvorrichtung auf, die eine sichtbare Darstellung eines Bildes auf der Grundlage der Bildinformationen entwickelt. In einem medizinischen Bildverarbeitungssystem kann die Eingangsabbildungsvorrichtung beispielsweise eine Diagnoseeinrichtung aufweisen, wie z. B. eine magnetische Resonanz-(MR-), Computertomographie- (CT-), eine herkömmliche Röntgen- oder Ultraschall-Einrichtung. Alternativ kann die Eingangsabbildungsvorrichtung eine Anwender-Schnittstelleneinrichtung aufweisen, wie z. B. eine Blocktastatur, eine Maus oder einen Trackball (Rollkugel), die gleichfalls medizinische Bildinformationen erzeugen können. Die Ausgangsabbildungsvorrichtung in einem medizinischen Bildverarbeitungssystem weist typischerweise einen digitalen Halbton-Laserbilderzeuger auf. Der Laserbilderzeuger belichtet als Reaktion auf die Bildinformation ein Abbildungsmedium zur Ausbildung der sichtbaren Darstellung.
Die durch die Eingangsabbildungsvorrichtung erzeugten Bildinformationen schließen Bilddaten, die digitale Bildwerte enthalten, welche das Bild repräsentieren, sowie Abbildungsanforderungen ein, die durch den Laserbilderzeuger auszuführende Operationen spezifizieren. Jeder der digitalen Bildwerte ent spricht einem von mehreren Pixeln im Originalbild und repräsentiert eine mit dem entsprechenden Pixel verbundene optische Dichte. Als Reaktion auf eine Abbildungsanforderung wandelt der Laserbilderzeuger die digitalen Bildwerte um und erzeugt Lasersteuerwerte, die zur Modulation der Intensität eines Abtastlasers verwendet werden. Die Lasersteuerwerte werden so berechnet, daß sie auf dem Abbildungsmedium Belichtungsstärken erzeugen, die zur Reproduktion der mit den Pixeln im Originalbild verbundenen optischen Dichten notwendig sind, wenn das Medium entweder durch chemische Naßverarbeitung oder durch thermische Trockenverarbeitung entwickelt wird. Der Laserbilderzeuger kann als Reaktion auf die durch die Eingangsabbildung erzeugten Abbildungsanforderungen eine Anzahl zusätzlicher Operationen ausführen. Zum Beispiel kann der Laserbilderzeuger die Bilddaten vor dem Erzeugen der Lasersteuerwerte manipulieren, um eine Vielzahl verschiedener Format- und/oder Erscheinungseigenschaften zu erzeugen.
Die durch den Laserbilderzeuger verarbeiteten Bildinformationen haben ein Format, das durch ein Eingangsprotokoll festgelegt wird, das mit der entsprechenden Eingangsabbildungsvorrichtung verknüpft ist. Medizinische Bildverarbeitungssysteme sind vorzugsweise in der Lage, Bildinformationen zu handhaben, die nach den verschiedensten Eingangsprotokollen erzeugt werden. Ein Eingangsprotokoll läßt sich so charakterisieren, daß es ein Eingangstreiberprotokoll, welches Bedingungen für die Kommunikation mit einer bestimmten Eingangsabbildungsvorrichtung festlegt, und ein Eingangsinterpretiererprotokoll aufweist, welches das Format für die Interpretation von Bildinformationen festlegt, die durch die Eingangsabbildungsvorrichtung erzeugt werden. Die Anzahl verschiedener Eingangsprotokolle ergibt sich bis zu einem gewissen Grade aus den verschiedenen Typen der gegenwärtig verwendeten Eingangsabbildungsvorrichtungen, z. B. MR-, CT-, Röntgen-, Ultraschall- Abbildungsvorrichtungen, deren jede Bildinformationen nach einem anderen Protokoll erzeugen kann. Die Hauptquelle für unterschiedliche Eingangsprotokolle ist jedoch die Existenz einer Anzahl von Modalitäten, d. h. von Eingangsabbildungsvorrichtungen, die von verschiedenen Herstellern produziert wer den und eindeutig bestimmte, herstellerspezifische Eingangsprotokolle aufweisen. Zum Beispiel stellen gegenwärtig Hersteller wie z. B. Siemens, Toshiba, GE und Picker Eingangsabbildungsvorrichtungen vom CT-Typ her, die eine ähnliche Funktionsvielfalt bereitstellen, aber Bildinformationen nach unterschiedlichen, modalitätsspezifischen Eingangsprotokollen erzeugen.
Außer der Fähigkeit zur Verarbeitung mehrerer Eingangsprotokolle können medizinische Systeme vorzugsweise die Übermittlung von Bildinformationen zu Ausgangsabbildungsvorrichtungen gemäß mehreren Ausgangsprotokollen abwickeln. Ebenso wie ein Eingangsprotokoll läßt sich ein Ausgangsprotokoll so charakterisieren, daß es ein Ausgangstreiberprotokoll, welches Bedingungen für die Kommunikation mit einer bestimmten Ausgangsabbildungsvorrichtung festlegt, und ein Ausgangsinterpretiererprotokoll aufweist, welches das Format für die Übersetzung von Bildinformationen in eine für die Ausgangsabbildungsvorrichtung verständliche Form festlegt. Unterschiedliche Ausgangsprotokolle ergeben sich aus der Verfügbarkeit von Laserbilderzeugungs-Ausgabevorrichtungen mit unterschiedlichen Sätzen von Funktionsmerkmalen. Die verschiedenen Sätze von Funktionsmerkmalen stellen eine unterschiedliche Komplexität dar, die zu verschiedenen Ausgangsprotokollen führen kann. Zum Beispiel bietet die Minnesota Mining & Manufacturing Company ("3M), St. Paul, Minnesota, gegenwärtig Laserbilderzeuger mit verschiedenen Funktionsmerkmalssätzen an, die als "831"-, "952"- und "SuperSet"-Sätze bezeichnet werden und jeweils mit einem satzspezifischen Ausgangsprotokoll verbunden sind.
Existierende medizinische Bildverarbeitungssysteme können gegenwärtig mehrere Eingangs- und Ausgangsprotokolle auf Ad-hoc-Basis durch die Konstruktion einer Hardware- und/oder Softwareschnittstelle unterbringen, die speziell für ein bestimmtes Eingangsprotokoll und ein bestimmtes Ausgangsprotokoll konfiguriert ist. Die Verwendung einer kundenspezifischen Schnittstelle ist äußerst inflexibel. Wenn später eine Kommunikation mit einer anderen Eingangsabbildungsvorrichtung erforderlich ist, muß die gesamte Schnittstelle umkonstruiert werden, um die Beziehung zwischen dem neuen Eingangsprotokoll und dem alten Ausgangsprotokoll zu handhaben. Eine Veränderung an der Ausgangsabbildungsvorrichtung erfordert entsprechend eine Umkonstruktion der Schnittstelle zur Handhabung der Beziehung zwischen dem neuen Ausgangsprotokoll und dem alten Eingangsprotokoll. Leider ist die Umkonstruktion der Schnittstelle eine beschwerliche Aufgabe, die oft einen bedeutenden Aufwand an Hardware- und/oder Software-Entwicklungszeit erfordert. Selbst scheinbar geringfügige Modifikationen an der Funktionsvielfalt einer Eingangs- oder Ausgangsabbildungsvorrichtung können zahlreiche, teure Konstruktionsänderungen zeitigen, die sich durch die gesamte Schnittstelle ausbreiten.
Nichtsdestoweniger gibt es zunehmende Forderungen nach flexibleren medizinischen Bildverarbeitungssystemen, die eine Kommunikation zwischen den verschiedensten Eingangs- und Ausgangsabbildungsvorrichtungen mit Mehrfachprotokollen bereitstellen können. Es ist wünschenswert, daß derartige medizinische Bildverarbeitungssysteme nicht nur Flexibilität bezüglich gegenwärtiger Protokolle bieten, sondern auch auf kostengünstige Weise an die Handhabung zukünftiger Protokolle angepaßt werden können. Existierende medizinische Bildverarbeitungssysteme erfüllen im allgemeinen die obigen Anforderungen nicht.
Nach dem Stand der Technik werden Systeme zur Übertragung von Daten von einer von mehreren Datenquelleneinrichtungen zu einer von mehreren Datenzieleinrichtungen unter der Steuerung eines zentralen Managers offenbart. Nach der US-A-5 060 140 können innerhalb einer endlichen Kapazität ein oder mehrere Pfade auf Operator-Befehl verbunden oder getrennt werden, ohne bestehende Systemverbindungen und -funktionen zu unterbrechen. Andererseits befaßt sich die US-A-S 339 413 besonders mit einem geeigneten Datenstreaming-Protokoll.

Zusammenfassung der Erfindung

Angesichts der Beschränkungen bestehender medizinischer Bildverarbeitungssysteme betrifft die vorliegende Erfindung ein medizinisches Bildverarbeitungssystem zur Übermittlung von Bildinformationen zwischen mehreren verschiedenen Eingangsabbildungsvorrichtungen mit unterschiedlichen Eingangsprotokollen und mehreren verschiedenen Ausgangsabbildungsvorrichtungen mit unterschiedlichen Ausgangsprotokollen. Die Erfindung ist in Anspruch 1 dargelegt.
Das erfindungsgemäße System nutzt eine wiederverwendbare Software-Architektur mit mehreren funktionell unabhängigen Komponenten. Die einzelnen Komponenten können in einer Kommunikationspipeline zur Übermittlung von Bildinformationen zwischen einer Eingangsabbildungsvorrichtung und einer Ausgangsabbildungsvorrichtung entsprechend gewünschten Protokollen konfiguriert werden. Jede Komponente kann gegen eine anders konfigurierte Komponente ausgetauscht werden, um die Übermittlung von Bildinformationen nach einem anderen Protokoll zu erleichtern, wodurch die Pipeline umkonfiguriert wird, um eine beträchtliche Flexibilität zu erzielen. Als weiterer Vorteil kann die Kommunikationspipeline dynamisch konfiguriert werden, um Komponenten einzubauen, die für die gegenwärtige Umgebung geeignet sind.
Außerdem ist die Software-Architektur skalierbar, um mehrere Kommunikationspipelines zu erzeugen, die jeweils entsprechend gewünschten Protokollen konfiguriert werden können. Folglich kann das erfindungsgemäße System ein anderes Protokoll unterstützen, indem es entweder Komponenten ein- und auslagert, um eine einzelne Kommunikationspipeline zu konfigurieren, oder einfach unter mehreren unterschiedlich konfigurierten Kommunikationspipelines in der skalierbaren Architektur eine alternative Pipeline auswählt.
Da ferner jede der Komponenten isoliert und funktionelle unabhängig ist, können, wenn die Neuentwicklung einer Komponente notwendig ist, mehrere Programmierer bei geringen zusätzlichen Allgemeinkosten mit der Arbeit betraut werden, wodurch Zeit und Kosten eingespart werden. Der modulare Aufbau der Architektur ermöglicht außerdem die Ausführung notwendiger Modifikationen oder Korrekturen an einer einzelnen Komponente mit geringer Auswirkung auf das Gesamtsystem.
Weitere Merkmale und Vorteile der vorliegenden Erfindung werden teils in der nachstehenden Beschreibung dargelegt, teils gehen sie aus der Beschreibung hervor oder sind aus der praktischen Anwendung der vorliegenden Erfindung zu entnehmen. Die Vorteile der vorliegenden Erfindung werden durch Mittel realisiert und erzielt, die in der schriftlichen Beschreibung und den Ansprüchen sowie in den beigefügten Zeichnungen hierzu besonders aufgezeigt werden.

Kurze Beschreibung der Zeichnungen

Die beigefügten Zeichnungen wurden zum besseren Verständnis der vorliegenden Erfindung aufgenommen und sind in diese Beschreibung einbezogen und bilden einen Teil davon. Die Zeichnungen veranschaulichen beispielhafte Ausführungsformen der vorliegenden Erfindung und dienen zusammen mit der Beschreibung zur Erläuterung der Grundgedanken der Erfindung.
Fig. 1 zeigt ein Blockschaltbild eines medizinischen Bildverarbeitungssystems zur Übermittlung von Bildinformationen zwischen Mehrfachprotokoll-Bildverarbeitungsvorrichtungen gemäß der vorliegenden Erfindung;
Fig. 2 zeigt ein Diagramm der Beziehung zwischen mehreren verschiedenen Protokollen und einem Satz von Basisklassenprotokollen gemäß der vorliegenden Erfindung und
Fig. 3 zeigt ein Blockschaltbild einer Benutzer- Dienstrechner- bzw. Client-Server-Beziehung gemäß der vorliegenden Erfindung, die auf das in Fig. 1 dargestellte medizinische Bildverarbeitungssystem anwendbar ist.

Ausführliche Beschreibung bevorzugter Ausführungsformen

Fig. 1 zeigt ein Blockschaltbild eines medizinischen Bildverarbeitungssystems 10 zur Übermittlung von Bildinformationen zwischen Mehrfachprotokoll-Bildverarbeitungsvorrichtungen gemäß der vorliegenden Erfindung. Das medizinische Bildverarbeitungssystem 10 weist mehrere Eingangsabbildungsvorrichtungen 12, eine oder mehrere Eingangsschnittstellenkomponenten 14, eine oder mehrere Ausgangsschnittstellenkomponenten 16 und eine oder mehrere Ausgangsabbildungsvorrichtungen 18 auf. Jede der Eingangsschnittstellenkomponenten 14 weist eine Eingangstreiberkomponente 20 und eine Eingangsinterpretiererkomponente 22 auf. Jede der Ausgangsschnittstellenkomponenten 16 weist eine Ausgangsinterpretiererkomponente 24 und eine Ausgangstreiberkomponente 26 auf. Eine Schnittstellenablaufkomponente 28 definiert eine oder mehrere (1 bis N) Kommunikationspipelines 30. Jede Kommunikationspipeline 30 verbindet kommunikativ eines der Eingangsabbildungsvorrichtungen 12, eine der Eingangstreiberkomponenten 20 eine der Eingangsinterpretiererkomponenten 22, eine der Ausgangsinterpretiererkomponenten 24, eine der Ausgangstreiberkomponenten 26 und die Ausgangsabbildungsvorrichtung 18 in beiden Richtungen. Die Ausgangsabbildungsvorrichtung 18 kann mit jeder der Pipelines 30 auf gemeinschaftlicher Basis kommunizieren. Alternativ könnten mehrere Ausgangsabbildungsvorrichtungen 18 vorgesehen werden, deren jede mit einer besonderen Pipeline 30 kommunikativ verbunden ist.
Die Eingangsschnittstellenkomponenten 14, die Ausgangsschnittstellenkomponenten 16 und die Schnittstellenablaufkomponente 28 sind als Softwaresystem implementiert, das mit Eingangsabbildungsvorrichtungen 12 und einer Ausgangsabbildungsvorrichtung 18 verbunden ist. Das Softwaresystem kann als Teil einer Ausgangsabbildungsvorrichtung 18 implementiert werden, wie z. B. eines digitalen Halbton-Laserbilderzeugers, oder als Teil einer getrennten Vorrichtung, welche die Übermittlung von Bildinformationen zwischen Eingangsabbildungsvorrichtungen 12 und einer Ausgangsabbildungsvorrichtung 18 steuert. Die durch die Eingangsabbildungsvorrichtung 12 erzeugten Bildinformationen schließen sowohl Anforderungen für Abbildungsoperationen als auch Bilddaten ein, welche digitale Bildwerte enthalten, die ein durch die Ausgangsabbildungsvorrichtung 18 zu verarbeitendes Bild repräsentieren. Für die Zwecke der vorliegenden Beschreibung wird die Pipeline 30 so beschrieben, daß sie die Übermittlung von Bildinformationen in Form von Abbildungsanforderungen abwickelt, wobei Bildinformationen in Form von digitalen Bildwerten, die das Bild repräsentieren, auf einem separaten Kommunikationsweg übermittelt werden. Es ist jedoch denkbar, daß die Pipeline 30 so konfiguriert werden könnte, daß sie die Übermittlung von Bildinformationen sowohl in Form von Anforderungen für Abbildungsoperationen als auch in Form von Bilddaten, welche die digitalen Bildwerte enthalten, abwickelt.
Jede der Eingangsschnittstellenkomponenten 14 ist so konfiguriert, daß sie die Bildinformationen über eine der Eingangstreiberkomponenten 20 von einer Eingangsabbildungs vorrichtung 12 nach einem von mehreren verschiedenen Eingangsschnittstellenprotokollen empfängt. Jedes Eingangsschnittstellenprotokoll ist spezifisch mit einer der Eingangsabbildungsvorrichtungen 12 verbunden und spiegelt die modalitätsspezifischen Bedingungen für die Kommunikation mit der jeweiligen Eingangsabbildungsvorrichtung wider. Außerdem ist jede der Eingangsschnittstellenkomponenten 14 so konfiguriert, daß sie auf der Basis des Inhalts der empfangenen Bildinformationen mittels einer der Eingangsinterpretiererkomponenten 22 erste Abbildungsanforderungen nach einem der Eingangsschnittstellenprotokolle erzeugt. Die ersten Abbildungsanforderungen repräsentieren durch die Eingangsabbildungsvorrichtung 12 erzeugte, durch die Eingangsinterpretiererkomponente 22 übersetzte Anweisungen zur Übermittlung an die Ausgangsschnittstellenkomponente 16.
Jede der Ausgangsschnittstellenkomponenten 16 ist so konfiguriert, daß sie auf der Basis des Inhalts der ersten Abbildungsanforderung mittels einer der Ausgangsinterpretiererkomponenten 24 zweite Abbildungsanforderungen nach einem von mehreren verschiedenen Ausgangsprotokollen erzeugt. Die zweiten Abbildungsanforderungen repräsentieren den Inhalt der ersten Abbildungsanforderungen, übersetzt durch die Ausgangsinterpretiererkomponente 24, zur Übermittlung an die Ausgangsabbildungsvorrichtung 18. Jedes Ausgangsschnittstellenprotokoll ist spezifisch mit dem Typ der Ausgangsabbildungsvorrichtung 18 verbunden und spiegelt, ebenso wie das Eingangsschnittstellenprotokoll, die Bedingungen für die Kommunikation mit der jeweiligen Ausgangsabbildungsvorrichtung wider. Außerdem ist jede der Ausgangsschnittstellenkomponenten 16 so konfiguriert, daß sie die zweiten Abbildungsanforderungen über die Ausgangstreiberkomponente 26 nach einem der Ausgangsschnittstellenprotokolle zur Ausgangsabbildungsvorrichtung 18 übermittelt.
Die Teilkomponenten der Eingangsschnittstellenkomponenten 14 und der Ausgangsschnittstellenkomponenten 16, d. h. die Eingangstreiberkomponente 20, die Eingangsinterpretiererkomponente 22, die Ausgangsinterpretiererkomponente 24 und die Ausgangstreiberkomponente 26, werden hier zusammen beschrieben, in Anerkennung der Tatsache, daß eine Eingangsschnittstellenkomponente sowie eine Ausgangsschnittstellenkomponente als ein einziger integrierter Softwarebaustein implementiert werden könnten. Es wird jedoch bevorzugt, eine Eingangsschnittstellenkomponente 14 durch eine getrennte Eingangstreiberkomponente 20 und eine getrennte Eingangsinterpretiererkomponente 22 zu realisieren und entsprechend eine Ausgangsschnittstellenkomponente 16 durch eine getrennte Ausgangsinterpretiererkomponente 24 und eine getrennte Ausgangstreiberkomponente 26 zu realisieren. Eine getrennte Implementierung der Teilkomponenten unterteilt die Funktionsvielfalt jeder Schnittstellenkomponente 14, 16 in kleinere Pakete, um eine bessere Modularität zu erzielen. Bei erhöhter Modularität erfordern beispielsweise Änderungen von Hardware-Schnittstellenspezifikationen für eine Eingangsabbildungsvorrichtung 12 nur eine Neukonfiguration der Eingangstreiberkomponente 20 anstatt der gesamten Eingangsschnittstellenkomponente 14.
Jedes der Eingangsschnittstellenprotokolle schließt sowohl ein auf Eingangstreiberkomponenten 20 anwendbares Eingangstreiberprotokoll als auch ein auf Eingangsinterpretiererkomponenten 22 anwendbares Eingangsinterpretiererprotokoll ein. Das passende Eingangstreiberprotokoll wird durch die Kommunikationsbedingungen einer bestimmten Eingangsabbildungsvorrichtung 12 festgelegt, während das passende Eingangsinterpretiererprotokoll durch das Bildinformationsformat der jeweiligen Eingangsabbildungsvorrichtung festgelegt wird. Das Bildinformationsformat bezieht sich auf die Typen von Abbildungsanforderungen, die nach dem Protokoll einer bestimmten Eingangsabbildungsvorrichtung 12 erzeugt werden. Das Eingangstreiberprotokoll spezifiziert, wie eine Eingangstreiberkomponente 20 die Übermittlung der Bildinformationen von einer Eingangsabbildungsvorrichtung 12 ausführen sollte. Das Eingangsinterpretiererprotokoll spezifiziert, wie eine Eingangsinterpretiererkomponente 22 die Bildinformationen interpretieren sollte, um die ersten Abbildungsanforderungen zu erzeugen. Die Eingangstreiber- und Eingangsinterpretiererprotokolle können entsprechend den unterschiedlichen Typen der Eingangsabbildungsvorrichtung 12, z. B. MR-, CT-, herkömmliche Röntgen-, Ultra schallvorrichtung, sowie in Abhängigkeit vom Hersteller der Eingangsabbildungsvorrichtung, z. B. Siemens, Toshiba, GE oder Picker, erheblich variieren.
Jedes der Ausgangsschnittstellenprotokolle schließt ein auf Ausgangsinterpretiererkomponenten 24 anwendbares Ausgangsinterpretiererprotokoll und ein auf Ausgangstreiberkomponenten 26 anwendbares Ausgangstreiberprotokoll ein. Das Ausgangstreiberprotokoll wird durch die Kommunikationsbedingungen der Ausgangsabbildungsvorrichtung 18 festgelegt, während das passende Ausgangsinterpretiererprotokoll durch dass Bildinformationsformat der Ausgangsabbildungsvorrichtung festgelegt wird. Das Ausgangsinterpretiererprotokoll spezifiziert, wie eine Ausgangsinterpretiererkomponente 24 erste Abbildungsanforderungen interpretieren sollte, um zweite Abbildungsanforderungen in einer für die Ausgangsabbildungsvorrichtung 18 verständlichen Weise zu erzeugen. Das Ausgangstreiberprotokoll spezifiziert, wie eine Ausgangstreiberkomponente 20 die Übertragung von zweiten Abbildungsanforderungen zur Ausgangsabbildungsvorrichtung 18 ausführen sollte. Ebenso wie die Eingangsschnittstellenprotokolle sind die Ausgangsschnittstellenprotokolle einer Veränderung unterworfen. Zum Beispiel können sowohl das Ausgangstreiber- als auch das Ausgangsinterpretiererprotokoll in Abhängigkeit vom Typ der durch die Ausgangsabbildungsvorrichtung 18 bereitgestellten Funktionsmerkmale variieren, z. B. 831, 952 oder Superset im Falle eines von 3M hergestellten Laserbilderzeugers.
Ungeachtet der für ein bestimmtes Protokoll spezifischen Funktionen sind die Komponenten 20, 22, 24, 26 vom gleichen Typ, z. B. sind alle Eingangstreiberkomponenten so konfiguriert, daß sie mehrere gemeinschaftliche Aufgaben ausführen. Zum Beispiel teilen sich die Eingangstreiberkomponenten 20 in einen Satz von gemeinsamen Aufgaben, die für die Kommunikation mit einer bestimmten Eingangsabbildungsvorrichtung 12 notwendig sind. Eine Eingangstreiberkomponente 20 ist so konfiguriert, daß sie etwaige Hardwarespezifika verarbeitet, wie z. B. Programmunterbrechungen (Interrupts), Puffer und Quittungsbetrieb (Hand-shaking), die zur Übermittlung von Bildinformationen nach und von einer bestimmten Eingangsabbildungsvor richtung 12 notwendig sind. Die Eingangstreiberkomponente 20 ist ferner so konfiguriert, daß sie etwaige andere spezifische Bedürfnisse der Eingangsabbildungsvorrichtung 12 erledigt, wie z. B. Paketieren oder Initialisieren. Die Eingangstreiberkomponente 20 führt alle notwendigen Kommunikationsaufgaben aus und isoliert den Rest der Pipeline 30 von jeder Kenntnis, daß die Kommunikation über eine serielle Schnittstelle, eine parallele Schnittstelle, eine Netzwerkschnittstelle oder irgendeinen anderen Mechanismus ausgeführt wird. Zusammenfassend läßt sich sagen, daß die Eingangstreiberkomponente 20 eine zweifache Verantwortung trägt. Erstens empfängt die Eingangstreiberkomponente 20 Bildinformationen von der Eingangsabbildungsvorrichtung 12 und bereitet die Bildinformationen für die nächste Stufe der Pipeline 30 auf, d. h. für die Eingangsinterpretiererkomponente 22. Zweitens überträgt die Eingangstreiberkomponente 20 etwaige Antworten, die aus der bidirektionalen Pipeline 30 hervorgehen, zur Eingangsabbildungsvorrichtung 12, wie weiter unten näher erläutert wird.
Die Eingangsinterpretiererkomponente 22, die nächste Komponente in der Pipeline 30, teilt gleichfalls einen gemeinsamen Aufgabensatz mit anderen Eingangsinterpretiererkomponenten, ohne Rücksicht auf ein spezifizisches Eingangsinterpretiererprotokoll. Nach Erhalt einer Bildinformation von einer Eingangstreiberkomponente 20 analysiert die Eingangsinterpretiererkomponente 22 zunächst Anforderungen, die in der Bildinformation enthalten sind, und übersetzt sie, um erste Abbildungsanforderungen zu erzeugen, die Operationen entsprechen, welche von der Ausgangsabbildungsvorrichtung 18 bereitgestellt werden. Die ersten Abbildungsanforderungen schließen Anforderungen für die verschiedensten gemeinsamen Abbildungsleistungen ein, die von der Ausgangsabbildungsvorrichtung 18 bereitgestellt werden. In einem typischen medizinischen Bildverarbeitungssystem können solche Anforderungen beispielsweise Anforderungen zur Auslösung eines Bilddruckauftrags durch die Ausgangsabbbildungsvorrichtung 18, Anforderungen zum Abbruch eines früher ausgelösten Bilddruckauftrags, Anforderungen zum Definieren oder Modifizieren eines Formats eines zu druckenden Bildes, Anforderungen zum Löschen eines Satzes von Bilddaten, die ein früher erfaßtes Bild darstellen, und Anforderungen zum Speichern von Bilddaten in einer bestimmten Bildspeicherzelle aufweisen.
Die Art und Weise, in der die Eingangsinterpretiererkomponente 22 die durch die Eingangsabbildungsvorrichtung 12 erzeugten Anforderungen interpretiert, kann entsprechend dem spezifischen Eingangsinterpretiererprotokoll variieren. Die Eingangsinterpretiererkomponente 22 versteht das exakte Format, die Anweisungen und Zeitsteuerungsbeschränkungen, die den durch eine bestimmte Eingangsabbildungsvorrichtung 12 erzeugten den Bildinformationen innewohnen. Trotzdem bieten alle Eingangsinterpretiererkomponenten 22 noch eine gemeinsame Grundfunktion zur Erzeugung von ersten Abbildungsanforderungen. Die Eingangsinterpretiererkomponente 22 sendet die ersten Abbildungsanforderungen auf der Pipeline 30. Sobald die ersten Abbildungsanforderungen durch flußabwärts liegende Komponenten in der bidirektionalen Pipeline 30 verarbeitet worden sind und eine Antwort empfangen worden ist, erzeugt die Eingangsinterpretiererkomponente 20 eine entsprechende Antwort für die Eingangsabbildungsvorrichtung 12. Die Eingangsinterpretiererkomponente 22 sendet die Antwort auf der Pipeline 30 zur Eingangsabbildungsvorrichtung 12 über die Eingangstreiberkomponente 20, welche die notwendigen Kommunikationsbedingungen zur Übertragung der Antwort zur Eingangsabbildungsvorrichtung abwickelt.
Die Ausgangsinterpretiererkomponente 24 ist die dritte Komponente in der Pipeline 30. Die Ausgangsabbildungsvorrichtung 18 kann eines von vielen verschiedenen Protokollen verkünden, wie z. B. 831, 952 oder Superset im Falle eines von 3M hergestellten Laserbilderzeugers. Ein Ausgangsinterpretiererkomponente 24 ist so konfiguriert, daß sie über die Pipeline 30 erste Abbildungsanforderungen empfängt, die durch eine Eingangsinterpretiererkomponente 22 erzeugt werden, und die ersten Abbildungsanforderungen interpretiert, um zweite Abbildungsanforderungen zu erzeugen, die im Einklang mit dem jeweiligen Protokoll sind, das durch die Ausgangsabbildungsvorrichtung 18 gefordert wird. Die zweiten Abbildungsanforderungen entsprechen im wesentlichen den ersten Abbildungsanforderun gen, sind aber entsprechend dem für die Ausgangsabbildungsvorrichtung 18 verständlichen Ausgangsprotokoll konfiguriert. Folglich dienen die zweiten Abbildungsanforderungen als Anforderungen für die gleichen Abbildungsdienste, die durch die ersten Abbildungsanforderungen spezifiziert werden. Die Art und Weise, in der eine Ausgangsinterpretiererkomponente 24 die Anweisungen interpretiert, kann entsprechend dem konkreten, durch die Ausgangsabbildungsvorrichtung 18 vorgeschriebenen Ausgangsinterpretiererprotokoll variieren, aber alle Ausgangsinterpretiererkomponenten 24 haben eine gemeinsame Aufgabe zur Erzeugung von zweiten Abbildungsanforderungen in einem Protokoll, das von der Ausgangsabbildungsvorrichtung verstanden wird. Die Ausgangsinterpretiererkomponente 24 sendet die zweiten Abbildungsanforderungen auf der Pipeline 30. Wenn die Ausgangsabbildungsvorrichtung 18 die zweiten Abbildungsanforderungen verarbeitet und eine Antwort formuliert, die über die Pipeline 30 empfangen wird, entfernt die Ausgangsinterpretiererkomponente 24 etwaige ausgangsprotokollspezifische Informationen und formt eine entsprechende Antwort für die Eingangsinterpretiererkomponente 22.
Die Ausgangstreiberkomponente 26 ist die vierte Komponente in der Pipeline 30. Ebenso wie Eingangstreiberkomponenten 20 führen alle Ausgangstreiberkomponenten 26 einen gemeinsamen Satz von Kommunikationsaufgaben aus. Konkret ist eine Ausgangstreiberkomponente 26 so konfiguriert, daß sie etwaige Hardwarespezifika verarbeitet, wie z. B. Programmunterbrechungen, Puffer und Quittungsbetrieb, die zur Übertragung von Abbildungsinformationen nach und von einer bestimmten Ausgangsabbildungsvorrichtung 18 notwendig sind. Die Ausgangstreiberkomponente 26 isoliert den Rest der Pipeline 30 von jeder Kenntnis, daß die Kommunikation mit der Ausgangsabbildungsvorrichtung 18 über eine serielle Schnittstelle, eine parallele Schnittstelle oder einen RAM mit Doppelzugriff ausgeführt wird. Die Ausgangstreiberkomponente 26 überträgt zweite Abbildungsanforderungen, die durch eine Ausgangsinterpretiererkomponente 24 erzeugt werden, unter Beibehaltung etwaiger Kommunikationsbedingung zur Ausgangsabbildungsvorrichtung 18. Ferner empfängt die Ausgangstreiberkomponente 26 Antworten von der Ausgangsabbildungsvorrichtung 18 und bereitet die Antwort für die Übertragung über die bidirektionale Pipeline 30 zur Ausgangsinterpretiererkomponente 24 vor.
Die Schnittstellenablaufkomponente 28, welche die Struktur der Pipeline 30 definiert, ist die fünfte Komponente des Softwaresystems. Die Schnittstellenablaufkomponente 28 ist so konfiguriert, daß sie eine Anzahl von Komponenten 20, 22, 24, 26 mit verschiedenen Protokollen auf einer ausgewählten Basis kommunikativ miteinander verbindet, um für eine erhebliche Flexibilität zu sorgen. Diese Flexibilität liefert ein medizinisches Bildverarbeitungssystem 10, das in der Lage ist, eine Kommunikation zwischen einer Reihe verschiedener Eingangsabbildungsvorrichtungen 12 und einer oder mehreren Ausgangsabbildungsvorrichtungen 18 mit eine r Reihe verschiedener Funktionsmöglichkeiten herzustellen. Folglich behandelt die Schnittstellenablaufkomponente 28 jede funktionell unabhängige Komponente 20, 22, 24, 26 als einen Block mit einem deutlich gekennzeichneten Satz von Verantwortungen und einer definierten Schnittstelle. Die Schnittstellenablaufkomponente 28 wählt die entsprechende Reihe von Black-boxes auf der Basis der Umgebung und verbindet sie miteinander, um die vollständige Pipeline 30 zu bilden. Als weiterer Vorteil ist die Schnittstellenablaufkomponente 28 vorzugsweise so konfiguriert, daß sie die Komponenten dynamisch zu einer Kommunikationspipeline 30 verbindet, die für die aktuelle Bildverarbeitungsumgebung geeignet ist. Außerdem ist die Schnittstellenablaufkomponente so konfiguriert, daß sie eine skalierbare Software-Architektur mit mehreren (1 - N) Kommunikationspipelines 30 erzeugt, die gemäß unterschiedlichen Protokollen konfiguriert sind. Die skalierbare Architektur befähigt die Ausgangsabbildungsvorrichtung 18, gleichzeitig mit mehreren Eingangsabbildungsvorrichtungen 12 auf gemeinschaftlicher Basis zu kommunizieren, wobei die notwendigen, von jeder Pipeline 30 bereitgestellten Protokolle verwendet werden. Als Alternative können mehrere Ausgangsabbildungsvorrichtungen 18 vorgesehen werden, die jeweils mit einer besonderen Pipeline 30 kommunikativ verbunden sind.
Die Schnittstellenablaufkomponente 28 skaliert die Software-Architektur so, daß sie mit den Anforderungen der Umgebungen übereinstimmt, und erzeugt so viele Pipelines 30, wie es Eingangsabbildungsvorrichtungen 12 gibt, die eine Schnittstelle mit einer Ausgangsabbildungsvorrichtung 18 benötigen. Die Schnittstellenablaufkomponente 28 verbindet selektiv eine Reihe von Komponenten 20, 22, 24, 26 mit spezifischen Protokollen, die für die Anpassung an eine bestimmte Eingangsabbildungsvorrichtung 12, eine bestimmte Ausgangsabbildungsvorrichtung 18 und die erforderlichen Hardwareschnittstellen notwendig sind. Die Natur der Komponenten 20, 22, 24, 26 ermöglicht es, sie als Bausteine durch die Schnittstellenablaufkomponente 28 selektiv in eine Pipeline 30 einzufügen oder aus dieser herauszunehmen. Jede der Komponenten 20, 22, 24, 26 wird durch eine Serie von Softwareschnittstellen mit einer anderen Komponente des gleichen Typs, aber mit verschiedenem Protokoll, austauschbar gemacht. Konkret ist jede Komponente entsprechend einem bestimmten Protokoll konfiguriert, weist aber eine "Basisklassen"-Softwareschnittstelle auf, die das Protokoll in ein für jede Komponente des gleichen Typs auswählbares Basisklassenprotokoll übersetzt. Die Basisklassenschnittstelle wird vorzugsweise in jede Komponente eingebaut, so daß jede Komponente 20, 22, 24, 26 in einer Pipeline 30 ausgewechselt werden kann, ohne die Konfiguration der anderen Komponenten in der Pipeline zu beeinflussen. Folglich können Einzelkomponenten 20, 22, 24, 26 auch wiederverwendet werden, wodurch die früher mit Neuentwicklungsarbeiten verbundenen Kosten wesentlich reduziert werden.
Wenn beispielsweise die Pipeline 30 für die Kommunikation zwischen einer Siemens-Eingangsabbildungsvorrichtung 12 und einer die 3M SuperSet-Funktionsvielfalt realisierenden Ausgangsabbildungsvorrichtung 18 zu konfigurieren wäre, gänzlich mittels serieller Daten, dann würde die Schnittstellenablaufkomponente 28 kommunikativ miteinander verbinden: (1) eine Eingangstreiberkomponente 20 mit einem Eingangstreiberprotokoll, das für den Empfang von Abbildungsinformationen über eine serielle Hardwareschnittstelle geeignet ist, die mit der Siemens-Eingangsabbildungsvorrichtung verbunden ist, (2) eine Eingangsinterpretiererkomponente 22 mit einem Eingangsinterpretiererprotokoll, das für die Erzeugung von ersten Abbildungsanforderungen geeignet ist, die auf dem Format der von der Siemens-Eingangsabbildungsvorrichtung empfangenen Abbildungsinformationen basieren, (3) eine Ausgangsinterpretiererkomponente 24 mit einem Ausgangsinterpretiererprotokoll, das für die Erzeugung von zweiten Abbildungsanforderungen geeignet ist, die von der 3M-SuperSet-Ausgangsabbildungsvorrichtung verstanden werden, und (4) eine Ausgangstreiberkomponente 26 mit einem Ausgangstreiberprotokoll, das für die Übermittlung der zweiten Abbildungsanforderungen über eine serielle Hardwareschnittstelle geeignet ist, die mit der 3M-Superset-Ausgangsabbildungsvorrichtung verbunden ist. Wenn als Alternative die oben beschriebene Pipeline 30 für die Kommunikation zwischen einer Toshiba-Eingangsabbildungsvorrichtung 12 und einer 3M Superset-Ausgangsabbildungsvorrichtung 18 zu modifizieren wäre, gänzlich mittels serieller Daten, dann müßten nur die Eingangstreiberkomponente 20 und die Eingangsinterpretiererkomponente 22 durch Komponenten ausgetauscht werden, die gemäß Eingangstreiber- bzw. Eingangsinterpretiererprotokollen konfiguriert sind, welche für die Toshiba-Modalität geeignet sind. Die Ausgangsschnittstellenkomponente 16, die eine für 3M Superset konfigurierte Ausgangsinterpretiererkomponente 24 und eine für 3M Superset seriell konfigurierte Ausgangstreiberkomponente 26 aufweist, wäre bereits nach den Bedingungen der Ausgangsabbildungsvorrichtung 18 konfiguriert, unabhängig von der Eingangsabbildungsvorrichtung 12, und würde daher durch die Modifikation nicht beeinflußt. Folglich würde die Schnittstellenablaufkomponente 28 kommunikativ miteinander verbinden: (1) eine Eingangstreiberkomponente 20 mit einem Eingangstreiberprotokoll, das für den Empfang von Abbildungsinformationen über eine serielle Hardwareschnittstelle geeignet ist, die mit der Toshiba-Eingangsabbildungsvorrichtung verbunden ist, (2) eine Eingangsinterpretiererkomponente 22 mit einem Eingangsinterpretiererprotokoll, das für die Erzeugung von ersten Abbildungsanforderungen geeignet ist, die auf dem Format der von der Toshiba-Eingangsabbildungsvorrichtung empfangenen Bildinformationen basieren, (3) eine Ausgangsinterpretiererkompo nente 24 mit einem Ausgangsinterpretiererprotokoll, das für die Erzeugung von zweiten Abbildungsanforderungen geeignet ist, die von der 3M Superset-Ausgangsabbildungsvorrichtung verstanden werden, und (4) eine Ausgangstreiberkomponente 26 mit einem Ausgangstreiberprotokoll, das für die Übermittlung der zweiten Abbildungsanforderungen über eine serielle Hardwareschnittstelle geeignet ist, die mit der 3M Superset-Ausgangsabbildungsvorrichtung verbunden ist.
Wenn als weitere Alternative die oben beschriebene Pipeline 30 für die Kommunikation zwischen einer Toshiba-Eingangsabbildungsvorrichtung 12 und einer 3M 952-Ausgangsabbildungsvorrichtung 18 zu konfigurieren wäre, gänzlich mittels serieller Daten, dann wäre nur eine Modifikation der Ausgangsschnittstellenkomponente 16 notwendig. Konkret würde die Schnittstellenablaufkomponente 28 kommunikativ miteinander verbinden: (1) eine Eingangstreiberkomponente 20 mit einem Eingangstreiberprotokoll, das für den Empfang von Abbildungsinformationen über eine serielle Hardwareschnittstelle geeignet ist, die mit der Toshiba-Eingangsabbildungsvorrichtung verbunden ist, (2) eine Eingangsinterpretiererkomponente 22 mit einem Eingangsinterpretiererprotokoll, das für die Erzeugung von ersten Abbildungsanforderungen geeignet ist, die auf dem Format der von der Toshiba-Eingangsabbildungsvorrichtung empfangenen Bildinformationen basieren, (3) eine Ausgangsinterpretiererkomponente 24 mit einem Ausgangsinterpretiererprotokoll, das für die Erzeugung von zweiten Abbildungsanforderungen geeignet ist, die von der 3M 952-Ausgangsabbildungsvorrichtung verstanden werden, und (4) eine Ausgangstreiberkomponente 26 mit einem Ausgangstreiberprotokoll, das für die Übermittlung der zweiten Abbildungsanforderungen über eine serielle Hardwareschnittstelle geeignet ist, die mit der 3M 952- Ausgangsabbildungsvorrichtung verbunden ist. Folglich würde die Eingangsschnittstellenkomponente 14, die eine allgemeine, seriell konfigurierte Eingangstreiberkomponente 20 und eine Toshiba-konfigurierte Eingangsinterpretiererkomponente 22 aufweist, durch die Modifikation nicht beeinflußt.
Wenn schließlich die oben beschriebene Pipeline 30 für die Kommunikation zwischen einer Toshiba-Eingangsabbildungs vorrichtung 12 mit einer seriellen Hardwareschnittstelle und einer 3M 952-Ausgangsabbildungsvorrichtung 18 mit einer Doppelzugriff-RAM-Schnittstelle zu modifizieren wäre, dann wäre nur die Modifikation der Ausgangsschnittstellenkomponente 16 notwendig. Konkret würde die Schnittstellenablaufkomponente 28 kommunikativ miteinander verbinden: (1) eine Eingangstreiberkomponente 20 mit einem Eingangstreiberprotokoll, das für den Empfang von Abbildungsinformationen über eine serielle Hardwareschnittstelle geeignet ist, die mit der Toshiba-Eingangsabbildungsvorrichtung verbunden ist, (2) eine Eingangsinterpretiererkomponente 22 mit einem Eingangsinterpretiererprotokoll, das für die Erzeugung von ersten Abbildungsanforderungen geeignet ist, die auf dem Format der von der Toshiba-Eingangsabbildungsvorrichtung empfangenen Abbildungsinformationen basieren, (3) eine Ausgangsinterpretiererkomponente 24 mit einem Ausgangsinterpretiererprotokoll, das für die Erzeugung von zweiten Abbildungsanforderungen geeignet ist, die von der 3M 952-Ausgangsabbildungsvorrichtung verstanden werden, und (4) eine Ausgangstreiberkomponente 26 mit einem Ausgangstreiberprotokoll, das für die Übermittlung der zweiten Abbildungsanforderungen über eine Doppelzugriff-RAM-Hardwareschnittstelle geeignet ist, die mit der 3M 952-Ausgangsabbildungsvorrichtung verbunden ist. Folglich würde die Eingangsschnittstellenkomponente 14, die eine allgemeine, seriell konfigurierte Eingangstreiberkomponente 20 und eine Toshiba-konfigurierte Eingangsinterpretiererkomponente 22 aufweist, durch die Modifikation nicht beeinflußt.
Um die Austauschbarkeit zu erleichtern, wie oben beschrieben, müssen die Softwareschnittstellen zwischen den Komponenten 20, 22, 24, 26 so vordefiniert werden, daß sie jeden Komponententyp auswählbar machen. Gleichzeitig muß jedoch eine Einzelkomponente 20, 22, 24, 26 so konfiguriert werden, daß sie Funktionen realisiert, die für ein bestimmtes Protokoll spezifisch sind. Gemäß der vorliegenden Erfindung liegt die Lösung in objektorientierten Verfahren, die verwendet werden, um ein auswählbares Basisklassenprotokoll für jeden Komponententyp zu entwickeln, z. B. für die Eingangstreiberkomponente 20. Das auswählbare Basisklassenprotokoll spezifiziert die durch eine Komponente bereitgestellten Funktionen und die Prozeduren für den Zugriff auf derartige Funktionen. Jede spezifische Protokollkomponente "erbt" von dem entsprechenden Basisklassenprotokoll und realisiert die Schnittstelle so, daß sie mit der Umgebung übereinstimmt. Der Begriff "Vererbung" wird hier benutzt, um eine objektorientierte Programmierungskonzeption zu bezeichnen, durch die abstrakte Datentypen erweitert werden können, um Typ/Untertyp-Beziehungen zu ermöglichen. Statt gemeinsam genutzte Eigenschaften neu zu realisieren, kann eine Klasse ausgewählte Datenelemente und Elementfunktionen anderer Klassen erben.
Die Klassenvererbung ermöglicht, daß Elemente einer Klasse so verwendet werden, als ob sie Elemente einer zweiten Klasse wären. Zur Realisierung der Unterklasse ist keine zusätzliche Programmierung erforderlich, mit Ausnahme derjenigen Operationen, welche die von der anderen Klasse geerbten Elemente entweder erweitern oder ersetzen. Bei der Entwicklung eines objektorientierten Systems werden aus bestehenden Klassen Unterklassen konstruiert, bis die geeignete Funktionsvielfalt entwickelt ist. Die Konstruktion von Unterklassen führt zur Bildung einer Klassenhierarchie. Die Klassenhierarchie hat ihre Wurzel in einer speziellen Klasse, die als Basisklasse bezeichnet wird. Die Basisklasse enthält ein minimales Verhaltensmuster (Satz von Verhaltensbedingungen), das allen Unterklassen gemeinsam ist. Gemäß der vorliegenden Erfindung ist jede Komponente 20, 22, 24, 26 nach einem spezifischen Protokoll konfiguriert, dient aber auch als Unterklasse des Basisklassenprotokolls. Da jede Komponente 20, 22, 24, 26 vom Basisklassenprotokoll erbt und eine minimale Menge von Funktionen so realisiert, daß diese die Basisklassen-Bedingungen erfüllen, kann sie direkt gegen jede andere Komponente vom gleichen Typ ausgetauscht werden, die von dem gleichen Basisklassenprotokoll erbt. Die aus den objektorientierten Verfahren resultierende Austauschbarkeit erzeugt eine "Direktverbindungs"-Software-Architektur, in der jede Komponente erfolgreich in die Pipeline 30 eingefügt werden kann, ohne eine zusätzliche Schnittstellenentwicklung zu benötigen.
Fig. 2 zeigt ein Beispiel einer objektorientierten Protokollhierarchie, welche die Austauschbarkeit der Komponenten 20, 22, 24, 26 erleichtert. Die Protokollhierarchie veranschaulicht die Realisierung der Komponenten 20, 22, 24, 26 für spezifische Protokolle, die jeweils von einem auswählbaren Basisklassenprotokoll "erben". Zum Beispiel kann ein Eingangstreiber-Basisprotokoll 32 mehrere "erbende" Eingangstreiberprotokolle für verschiedene Hardwareschnittstellenbedingungen umfassen, die mit einer Eingangsabbildungsvorrichtung 12 verbunden sind, wie z. B. ein allgemeines serielles Eingangstreiberprotokoll 34, ein SCSI-Eingangstreiberprotokoll 36, ein serielles Siemens-Eingangstreiberprotokoll 38 oder ein paralleles Eingangstreiberprotokoll 39. Ein Basisklassen-Eingangsinterpretiererprotokoll 40 kann mehrere erbende Eingangsinterpretiererprotokolle für verschiedene Typen von Eingangsabbildungsvorrichtungen 12 oder verschiedene Hersteller umfassen, wie z. B. ein GE-Eingangsinterpretiererprotokoll 42, ein Toshiba-Eingangsinterpretiererprotokoll 44, ein Siemens- Eingangsinterpretiererprotokoll 46 oder ein Picker-Eingangsinterpretiererprotokoll 48. Wie in Fig. 2 gezeigt, kann das Eingangsinterpretiererprotokoll 40 auch erbende Protokolle für Benutzerschnittstellenvorrichtungen umfassen, wie z. B. ein Blocktastatur-Protokoll 50.
Entsprechend kann ein Basisklassen-Ausgangsinterpretiererprotokoll 52 mehrere erbende Ausgangsinterpretiererprotokolle für verschiedene Typen von Ausgangsabbildungsvorrichtungen 18 umfassen, wie z. B. ein 3M SuperSet-Ausgangsinterpretiererprotokoll 54, ein 3M 831-Ausgangsinterpretiererprotokoll 56 oder ein 3M 952-Ausgangsinterpretiererprotokoll 58. Schließlich kann ein Basisklassen-Ausgangstreiberprotokoll 60 mehrere erbende Ausgangstreiberprotokolle für verschiedene Hardwareschnittstellenbedingungen umfassen, die mit der Ausgangsabbildungsvorrichtung 18 verbunden sind, wie z. B. ein Doppelzugriff-RAM-Ausgangstreiberprotokoll 62, ein serielles Ausgangstreiberprotokoll 64 oder ein paralleles Ausgangstreiberprotokoll 65. Jedes der oben beschriebenen erbenden Protokolle weist protokollspezifische Funktionen auf, die durch eine Komponente 20, 22, 24, 26 bereitgestellt wer den, realisiert aber derartige Funktionen über eine auswählbare Schnittstelle, die von dem entsprechenden Basisklassenprotokoll 32, 40, 52, 60 erbt. Für jedes oben beschriebene Basisklassenprotokoll 32, 40, 52, 60 können je nach den Bedingungen der Umgebung des medizinischen Bildverarbeitungssystems die verschiedensten zusätzlichen erbenden Protokolle realisiert werden.
Wie in Fig. 3 dargestellt, definiert die Schnittstellenablaufkomponente 28 vorzugsweise eine Pipeline 30 gemäß einer Client-Server-Architektur. In Fig. 3 deutet ein von einer Komponente A auf eine Komponente B zeigender Pfeil an, daß die Komponente A eine Client-Komponente (Bezieher) der Server-Komponente B (Dienstleister) ist. Die Zweirichtungspfeile zwischen der Eingangstreiberkomponente 20 und der Eingangsabbildungsvorrichtung 12 sowie zwischen der Ausgangstreiberkomponente 26 und der Ausgangsabbildungsvorrichtung 18 repräsentieren keine Client-Server-Beziehung, sondern statt dessen die Hardware/Software-Schnittstellen des medizinischen Bildverarbeitungssystems 10. Wie durch die Pfeile in Fig. 3 angedeutet, definiert die Schnittstellenablaufkomponente 28 vorzugsweise die Client-Server-Beziehung derart, daß die Eingangsinterpretiererkomponente 22 eine Client-Komponente sowohl der Eingangstreiberkomponente 20 als auch der Ausgangsinterpretiererkomponente 24 ist, und daß die Ausgangsinterpretiererkomponente 24 eine Client-Komponente der Ausgangstreiberkomponente 26 ist. Folglich sind die Eingangstreiberkomponente 20 und die Ausgangsinterpretiererkomponente 24 Server-Komponenten für die Eingangsinterpretiererkomponente 22, und die Ausgangstreiberkomponente 26 ist eine Server-Komponente für die Ausgangsinterpretiererkomponente 24. Die Schnittstellenablaufkomponente 28 selbst ist eine Client-Komponente der Eingangstreiberkomponente 20, der Eingangsinterpretiererkomponente 22, der Ausgangsinterpretiererkomponente 24 und der Ausgangstreiberkomponente 26.
In der oben beschriebenen Client-Server-Beziehung sind sowohl die Eingangstreiberkomponente 20 als auch die Ausgangstreiberkomponente 26 reine Server-Komponenten für die Eingangsinterpretiererkomponente 22 bzw. die Ausgangsinterpre tiererkomponente 24. Die Eingangstreiberkomponente 20 bzw. die Ausgangstreiberkomponente 26 sind für Hardware-Bedingungen auf niedriger Ebene verantwortlich und werden auf höherer Ebene von der Eingangsinterpretiererkomponente 22 bzw. der Ausgangsinterpretiererkomponente 24 gesteuert. Die Eingangsinterpretiererkomponente 22 ist eine Client-Komponente der Ausgangsinterpretiererkomponente 24, die einen Satz von Funktionen bereitstellt, durch welche die Eingangsinterpretiererkomponente die Ausgangsabbildungsvorrichtung 18 steuert. Die Ausgangsinterpretiererkomponente 24 initiiert nie eine Kommunikation mit der Eingangsinterpretiererkomponente 22, sondern liefert Dienstleistungen auf Anforderung der Eingangsinterpretiererkomponente. Schließlich ist jede Komponente 20, 22, 24, 26 eine Server-Komponente für die Schnittstellenablaufkomponente 28. Folglich steuert die Schnittstellenablaufkomponente 28 letzten Endes das gesamte Softwaresystem.
Die Kommunikation zwischen den Komponenten 20, 22, 24, 26, 28 in der Client-Server-Beziehung erfolgt durch die Ausgabe von Fernprozeduraufrufen (RPC). Ein Fernprozeduraufruf ist ein gemeinsamer Kommunikationsmechanismus, der in komplexen verteilten Softwaresystemen oft verwendet wird. Eine Client-Komponente führt eine bestimmte Funktion aus, indem sie einen Fernprozeduraufruf an eine entsprechende Server-Komponente ausgibt. Die Verwendung von Fernprozeduraufrufen verbirgt die spezifischen Details und Abhängigkeiten, d. h. die protokollspezifischen Eigenschaften, der einzelnen Komponenten. Der Fernprozeduraufruf wickelt alle Mechanismen ab, die für die Kommunikation zwischen den Komponenten notwendig sind. Als Ergebnis können die Kommunikationsmechanismen auswählbar bleiben, wodurch die Notwendigkeit für die Entwicklung protokollspezifischer Mechanismen in jeder Komponente entfällt. Jede Komponente 20, 22, 24, 26 ist so konfiguriert, daß sie Dienstleistungen für eine Client-Komponente bereitstellt, aber keine Kenntnis davon hat, welche oder wie viele Komponenten sie tatsächlich als Server-Komponente benutzen. Die Komponenten 20, 22, 24, 26 führen einfach die Anforderungen von Client-Komponenten aus, ohne protokollspezifische Abhängigkeiten aufzuweisen.
Ein Fernprozeduraufruf wird benutzt, um eine Funktion auf die folgende Weise auszuführen. Zunächst, wenn ein Softwareverfahren, das gerade von einer Client-Komponente ausgeführt wird, eine bestimmte Funktion ausführen muß, dann ruft das Verfahren einfach die Funktion durch ihren Bezeichner auf. Eine Sofware-Schicht, die sich innerhalb der Client-Komponente befindet und gewöhnlich als "Client-Stichleitung" (client stub) bezeichnet wird, fängt den Funktionsaufruf ab. Wenn die Client-Stichleitung feststellt, daß der Software-Code, der zur Ausführung der aufgerufenen Funktion notwendig ist, tatsächlich innerhalb einer anderen Server-Komponente existiert, dann erzeugt die Client-Stichleitung eine Meldung, die alle mit dem Funktionsaufruf weitergeleiteten Daten sowie jede notwendige Paketierung und Adressierung einschließt. Die Client-Stichleitung sendet dann die Meldung über das im Softwaresystem vorhandene Realzeit-Betriebssystem zur Server-Komponente. Der Server-Baustein enthält eine Software-Code-Schicht, die als Server-Stichleitung (server stub) bekannt ist und die Meldung empfängt. Die Server-Stichleitung löst die Meldung heraus und ruft tatsächlich die richtige lokale Funktion mit etwaigen aus der Meldung entnommenen Daten auf. Die lokale Funktion wird ausgeführt, als ob sie ursprünglich lokal aufgerufen würde, und gibt etwa angeforderte Informationen zurück. Die Server- Stichleitung erzeugt eine auf den zurückgegebenen Informationen basierende Antwort und sendet die Antwort über das Betriebssystem zur Client-Komponente. Nach Empfang der Antwort entnimmt die Client-Stichleitung die zurückgegebenen Informationen und leitet die Informationen zu dem lokalen Software- Verfahren weiter, das die Funktion ursprünglich aufgerufen hat. Das lokale Software-Verfahren läuft dann weiter ab, in Unkenntnis dessen, daß eine Kommunikation zwischen den Bausteinen stattgefunden hat.
Die folgenden Abschnitte liefern Details zu der Art und Weise, wie jedes Basisklassenprotokoll in einer als Beispiel angegebenen Ausführungsform des medizinischen Bildverarbeitungssystems 10 gemäß der vorliegenden Erfindung realisiert werden kann. Insbesondere werden in den Abschnitten A-D beispielhafte Definitionen und Bedingungen für Dienstleistungen angegeben, die durch jede der Komponenten 20, 22, 24, 26 bereitgestellt werden, zu Erläuterungszwecken dargestellt in der objektorientierten Programmiersprache C++, gegebenenfalls mit Kommentaren. Wo im folgenden der C++-Code verwendet wird, um die Funktionsvielfalt einer bestimmten Komponente an Beispielen zu erläutern, kann die Bezeichnung "Host" (Wirt) verwendet werden, um die Eingangsabbildungsvorrichtung 12 zu bezeichnen, und die Bezeichnung "Laserbilderzeuger" oder "LI" kann zum Bezeichnen der Ausgangsabbildungsvorrichtung 18 verwendet werden.

A. Das Eingangstreiber-Basisklassenprotokoll

Das Eingangstreiber-Basisklassenprotokoll in dieser als Beispiel dienenden Ausführungsform weist sieben Fernprozeduraufrufe auf, welche die Eingangstreiberkomponente 20 für ihre Client-Komponenten, die Schnittstellenablaufkomponente 28 und die Eingangsinterpretiererkomponente 22, bereitstellen muß. Mit den Fernprozeduraufrufen kann eine Client-Komponente direkt über die Eingangstreiberkomponente 20 mit einer externen Eingangsabbildungsvorrichtung 12 verbunden sein. Die sieben Fernprozeduraufrufe werden nachstehend hinsichtlich der verarbeiteten Parametertypen und der ausgeführten Funktionen beschrieben.
Der obige Fernprozeduraufruf (RPC) übergibt eine Meldung an die Eingangstreiberkomponente, um sie zur Eingangsabbildungsvorrichtung 12 zu übertragen. Alle Kommunikationsbedingungen für die Übertragung der Meldung zur Eingangsabbildungsvorrichtung 12 werden durch die Eingangstreiberkomponente 20 bearbeitet.
Der obige Fernprozeduraufruf (RPC) ruft eine Meldung von der Eingangstreiberkomponente 20 ab, die vom Host (Wirt) gesendet worden ist. Wieder werden alle Kommunikationsbedingungen für die Übertragung der Meldung zur Eingangsabbildungsvorrichtung 12 durch die Eingangstreiberkomponente 20 bearbeitet.
Der obige Fernprozeduraufruf setzt einen Zeitabschaltwert, den die Eingangstreiberkomponente 20 verwendet, wenn sie eine Meldung an die Eingangsabbildungsvorrichtung 12 sendet.
Der obige Fernprozeduraufruf übergibt an die Eingangstreiberkomponente -20 einen Zugriff auf eine mit der Client- Komponente verbundene asynchrone Routine (Handler, Hantierer). Der obige Fernprozeduraufruf bietet ein Mittel, durch das die Eingangstreiberkomponente 20 die Client-Komponente über ein eingetretenes asynchrones Ereignis informiert. Das einzige asynchrone Ereignis, das bezüglich der Eingangstreiberkomponente 20 auftritt, ist MSG_PENDING, welches anzeigt, daß durch die Eingangstreiberkomponente eine Meldung von der Eingangsabbildungsvorrichtung 12 vollständig empfangen worden ist und für die Eingangsinterpretiererkomponente 22 bereitsteht.
Der obige Fernprozeduraufruf (RPC) ermöglicht den Client-Komponenten, die Fehlersuchebene der Eingangstreiberkomponente 20 einzustellen. Die Fehlersuchebenen sind NO_DEBUG (keine Fehlersuche), LOW_DEBUG (geringe Fehlersuche), MEDIUM_DEBUG (mittlere Fehlersuche) und HIGH_DEBUG (strenge Fehlersuche). Dieser Parameter beeinflußt die während der Fehlersuche angezeigten Informationen.
Der obige Fernprozeduraufruf (RPC) aktiviert die Kommunikation zwischen der Eingangstreiberkomponente 20 und der Eingangsabbildungsvorrichtung 12.
Der obige Fernprozeduraufruf (RPC) deaktiviert die Kommunikation zwischen der Eingangstreiberkomponente 20 und der Eingangsabbildungsvorrichtung 12.
Wie oben angedeutet, gibt jeder Fernprozeduraufruf (RPC) von der Eingangstreiberkomponente 20 einen von drei Rücksprungcodes zurück: (1) RPC_OK (Fernprozeduraufruf o.k.), (2) PORT_BUSY (Kanal besetzt) und (3) NO_MESSAGE (keine Meldung). Die Treiber-Rücksprungcodes können in C++ wie folgt definiert werden:
Das eigentliche Basisklassenprotokoll für die Eingangstreiberkomponente 20 kann in C++ wie folgt definiert werden:

B. Das Eingangsinterpretierer-Basisklassenprotokoll

Das Eingangsinterpretierer-Basisklassenprotokoll in der vorliegenden beispielhaften Ausführungsform weist vier Fernprozeduraufrufe auf, welche die Eingangsinterpretiererkomponente 22 für ihre Client-Komponente, die Schnittstellenablaufkomponente 28, bereitstellen muß. Mit den Fernprozeduraufrufen kann die Schnittstellenablaufkomponente 28 mit der Eingangsinterpretiererkomponente 22 kommunizieren. Nachstehend werden die vier Fernprozeduraufrufe für die Eingangsinterpretiererkomponente 22 bezüglich der verarbeiteten Parametertypen und der ausgeführten Funktionen beschrieben.
Der obige Fernprozeduraufruf übergibt an die Eingangsinterpretiererkomponente 22 einen Zeiger, der auf Konfigurationsparameter für die Komponente zeigt. Die Parameter sind seit der letzten Stromabschaltsequenz des Systems 10 gespeichert. Die Parameter sind in einem Festwertblock eines Speichers abgelegt, der mit der Ausgangsabbildungsvorrichtung 18 verbunden ist. Folglich finden etwaige Änderungen, die durch die Eingangsinterpretiererkomponente 22 vorgenommen werden, keinen Niederschlag im nächsten Stromeinschaltvorgang.
Der obige Fernprozeduraufruf (RPC) empfängt asynchrone Ereignisse von der Eingangstreiberkomponente 20. Die asynchronen Ereignisse, die den Empfang von Meldungen von einer Eingangsabbildungsvorrichtung 12 einschließen, werden weiter oben im Zusammenhang mit der Eingangstreiberkomponente 20 beschrieben.
Der obige Fernprozeduraufruf (RPC) empfängt asynchrone Ereignisse von der Ausgangsabbildungsvorrichtung 18 über die Ausgangsinterpretiererkomponente 24 und die Ausgangstreiberkomponente 26. Die von der Ausgangsabbildungsvorrichtung 18 empfangenen asynchronen Ereignisse werden weiter unten im Zusammenhang mit der Ausgangsinterpretiererkomponente 24 ausführlicher beschrieben.
Der obige Fernprozeduraufruf gestattet der Client-Komponente, d. h. der Schnittstellenablaufkomponente 28, die Fehlersuchebene für die Eingangsinterpretiererkomponente 22 einzustellen. Zu den Fehlersuchebenen gehören: NO_DEBUG (keine Fehlersuche), LOW_DEBUG (geringe Fehlersuche), MEDIUM_DEBUG (mittlere Fehlersuche), HIGH_DEBUG (strenge Fehlersuche). Dieser Parameter beeinflußt die während der Fehlersuche angezeigte Information.
Wie oben festgestellt, liefert die Eingangsinterpretiererkomponente 22 einen Mechanismus zur Verarbeitung asynchroner Ereignisse, die von der Ausgangsabbildungsvorrichtung 18 empfangen werden. Die Ereignisse dienen zur Information der Eingangsinterpretiererkomponente 22 über eine Zustandsänderung an der Ausgangsabbildungsvorrichtung 18. Zu den verschiedenen Ereignissen, die den Zustand der Ausgangsabbildungsvorrichtung 18 anzeigen, können gehören: (1) FP_status_change, welches anzeigt, daß ein mit der Ausgangsabbildungsvorrichtung verbundener Filmprozessor seinen Zustand geändert hat, (2) PR status_change, welches anzeigt, daß eine mit der Ausgangsabbildungsvorrichtung verbundene Abbildungshardware ihren Zustand geändert hat, (3) IMS_status_change, welches anzeigt, daß ein Bildverwaltungssystem, das für die Formatierung von Bilddaten innerhalb der Ausgangsabbildungsvorrichtung verantwortlich ist, seinen Zustand geändert hat, (4) JOB_status_change, welches anzeigt, daß ein Abbildungsauftrag seinen Zustand geändert hat, und (S) XFR_status_change, welches anzeigt, daß ein Übertragungsauftrag, der eine Übertra gung von Bilddaten im Hintergrund betrifft, seinen Zustand geändert hat. Die Funktion der obigen Zustandsereignisse besteht darin, zu vermeiden, daß die Eingangsinterpretiererkomponente 22 ständig die Ausgangsabbildungsvorrichtung 18 abfragen muß.
Das eigentliche Basisklassenprotokoll für die Eingangsinterpretiererkomponente 22 kann in C++ wie folgt definiert werden:

C. Das Ausgangsinterpretierer-Basisklassenprotokoll

Die Eingangsinterpretiererkomponente 22 ist mit der Ausgangsinterpretiererkomponente 24 über einen Satz von Abbildungsobjekten verbunden. Die Abbildungsobjekte dienen als Pa rameter für die Fernprozeduraufrufe und enthalten alle verfügbaren Informationen, welche die Eigenschaften der Ausgangsabbildungsvorrichtung 18 und das Abbildungsverfahren betreffen. Die Eingangsinterpretiererkomponente 22 kann einen beliebigen Teil der Informationen verwenden und den Rest ignorieren. Es gibt sechs Abbildungsobjekt-Definitionen, zu denen gehören: (1) ein Boxobjekt (Kastenobjekt), (2) ein Formatobjekt, (3) ein Bildobjekt, (4) ein Testbildobjekt, (5) ein String-Objekt (Zeichenfolgenobjekt) und (6) eine Vielfalt von allgemeinen Abbildungsparameterobjekten.
Ein Formatobjekt wird benutzt, um ein ganzes Blatt eines Abbildungsmediums zu beschreiben, auf dem die Ausgangsabbildungsvorrichtung 18 ein Bild erzeugt. Das Formatobjekt enthält Informationen bezüglich des Filmtyps, der Filmgröße, der Randfarbe, der Randdichte usw. Die Eigenschaften des Formatobjekts lassen sich in C++ wie folgt definieren:
Eine Box ist ein rechteckiger Bereich des Filmblatts, der zur Aufnahme eines Bildes bestimmt ist. Die Box weist viele Eigenschaften auf, zu denen die Position, die Größe, der Kontrast, die Farbe usw. gehören. Die Box-Definitionen sind mit einem bestimmten Format verbunden. Das heißt, mehrere Boxen werden in Verbindung mit einem bestimmten Format verwen det. Der folgende C++-Code beschreibt ein Boxobjekt und seine Eigenschaften:
Ein Bild wird durch Bilddaten dargestellt, die digitale Bildwerte enthalten. Die Bilddaten werden in einem Bildspeicher abgelegt, der mit der Ausgangsabbildungsvorrichtung 18 verbunden ist. Das Bildobjekt wird benutzt, um gewisse Eigenschaften mit dem Bild zu verknüpfen. Wie durch den obigen Code angedeutet, können zu den Eigenschaften die Pixellänge, die Pixelbreite, die Pixeltiefe, das Farbformat usw. gehören. Beim Drucken wird ein Bild zum Füllen der Boxen bzw. Kästen verwendet, die für das zu benutzende Format definiert sind. Der nachstehende C++-Code beschreibt das Bildobjekt und seine Eigenschaften:
Ein Testbildobjekt dient zum Symbolisieren von Bildern, die zu Testzwecken verwendet werden. Die Bilder werden mittels Software erzeugt und weisen andere Attribute als ein Bild auf. Der folgende C++-Code beschreibt das Testbildobjekt und seine Eigenschaften:
Ein String-Objekt bzw. Zeichenfolgenobjekt dient zur Aufnahme von ASCII-Text im Bildspeicher. Das String-Objekt gestattet außerdem die Verwendung von Parametern wie z. B. Länge, Intensität, Typ usw. Der folgende C++-Code beschreibt das String-Objekt und seine Eigenschaften:
Das Objekt Allgemeine Parameter dient zur Aufnahme aller Verfahrensparameter. Dieses Objekt kann zum Einstellen der Parameter im Laserbilderzeuger oder zum Lesen der aktuellen Parametereinstellungen verwendet werden. Beispiele einiger Parameter sind Standard-Beta-Tabellen, der Standard-Farbkontrast, der Standard-Ziel, Standard-Filmgröße und -typ usw. Einige Parameter sind Festwertparameter und können daher nicht eingestellt werden, wie z. B. der verfügbare Speicherumfang, die aktuelle Software-Ausgabe, die Gesamtzahl der Druckaufträge in der Warteschlange usw. Der folgende C++-Code beschreibt das Objekt Allgemeine Parameter und seine Eigenschaften:
Eine der Hauptaufgaben der Ausgangsinterpretiererkomponente 24 ist die Weitergabe des Zustands der Ausgangsabbildungsvorrichtung 18 an die Client-Komponente, d. h. die Eingangsinterpretiererkomponente 22. Das Zustandsweitergabeverfahren weist zwei Schritte auf. Sobald die Ausgangsinterpretiererkomponente 24 eine Zustandsänderung in der Ausgangsabbildungsvorrichtung 18 feststellt, wird die Ereignisroutine in der Client-Komponente durch die Ausgangsinterpretiererkomponente direkt aufgerufen. Der Ereignisroutine wird ein Zustands- bzw. Statusereignis übergeben. Wiederum gehören zu den möglichen Zustandsereignissen, die weiter oben bezüglich des Eingangsinterpretierer-Basisklassenprotokolls beschrieben wurden: (1) FP_status_change, (2) PR_status_change, (3) IMS_ status_change, (4) JOB_status_change und (5) XFR_status_change. Die Ausgangsinterpretiererkomponente 24 teilt der Client-Komponente, d. h. der Eingangsinterpretiererkomponente 22, die obigen Zustandsänderungen mit, so daß die Eingangsinterpretiererkomponente nicht fortlaufend den Laserbilderzeuger abzufragen braucht.
Die Aufgabe der Client-Komponente, d. h. der Eingangsinterpretiererkomponente 22, besteht darin, entweder die Zustandsänderung zu ignorieren oder weitere Informationen anzufordern. Alle Zustandsinformationen sind in fünf Zustandsobjekten enthalten. Es gibt das Zustandsobjekt für den Filmprozessor, den Drucker, das Bildverwaltungssystem, Aufträge und Hintergrundaufträge (Übertragungen). Jedes Zustandsobjekt weist ein Zustandsfeld auf, das leicht kontrolliert werden kann, um zu erkennen, ob Warnungen oder Fehler vorliegen. Wenn Warnungen oder Fehler vorliegen, kann eine weitere Untersuchung der Warnungsstruktur oder der Fehlerstruktur ausgeführt werden. Wieder hat der Client die Wahl, nur die Informationen zu verwenden, die er benötigt. Der folgende C++-Code zeigt die Definition für jedes der Zustandsobjekte und die Strukturen, die sie enthalten:
Die Ausgangsinterpretiererkomponente 24 stellt in der vorliegenden beispielhaften Ausführungsform fünfzehn Typen von Fernprozeduraufrufen bereit. Bei Verwendung der oben beschriebenen Abbildungsobjekte und der Fernprozeduraufrufe kann der Client die Ausgangsabbildungsvorrichtung 18 vollständig betreiben. Zu beachten ist, daß alle Parameter, die in den oben beschriebenen Abbildungsobjekten enthalten sind, mit einem "nicht zugewiesenen Wert" initialisiert werden. Wenn der Parameter durch den Client verändert wird, ignoriert ihn die Ausgangsinterpretiererkomponente 24. Dieses Merkmal ermöglicht, daß der Client nur die Parameter verwendet, die er benötigt. Jeder der durch die Ausgangsinterpretiererkomponente 24 bereitgestellten Fernprozeduraufrufe wird im folgenden beschrieben. Wenn nicht anders angegeben, ist der Rücksprung für jeden der folgenden Fernprozeduraufrufe ein Laserbilderzeuger-Antwortobjekt vom Typ LI_response, das weiter unten in dieser Offenbarung näher erläutert wird.
Der obige Fernprozeduraufruf initiiert einen allgemeinen Ausdruck von einem Laserbilderzeuger, der als Ausgangsabbildungsvorrichtung 18 funktioniert. Der obige Fernprozeduraufruf ist so gestaltet, daß er mit fester Formatierung verwendet wird. Das Format ist ein aktuell gewähltes festes Format. "Kopien" ist ein wahlfreier Parameter, der die Anzahl der zu erzeugenden Kopien anzeigt. Für den Ausdruck werden die seit dem letzten Ausdruck erfaßten Bilder verwendet.
Der obige Fernprozeduraufruf initiiert einen Ausdruck vom Laserbilderzeuger. "Format" ist der zu benutzende Formatbezeichner. "Bildliste" zeigt an, welche Bilder zum Ausfüllen des Formats zu verwenden sind. "Kopien" ist ein wahlfreier Parameter, der die Anzahl der zu erzeugenden Kopien anzeigt. "Dichte" ist eine wahlfreie ganze Zahl, die zu verwenden ist, wenn eine Dichtetestfläche gewünscht wird. Der ganzzahlige Wert entspricht einem Bildbezeichner. "Ziel" ist ein wahlfreier Parameter, der ein Ziel für die Ausgabe statt des Standardziels definiert.
Der obige Fernprozeduraufruf initiiert einen Ausdruck vom Laserbilderzeuger. "Format" ist der zu benutzende Formatbezeichner. "Bildliste" zeigt an, welche Bilder zum Ausfüllen des Formats zu verwenden sind. "Dichtebezeichner" ist eine ganze Zahl, welche den Bildbezeichner in einer Dichtetestfläche darstellt. "Kopien" ist ein wahlfreier Parameter, der die Anzahl der zu erzeugenden Kopien anzeigt. "Ziel" ist ein wahlfreier Parameter, der ein Ziel für die Ausgabe statt des Standardziels definiert.
Der obige Fernprozeduraufruf bewirkt den Abbruch eines Auftrags mit dem entsprechenden Bezeichner.
Der obige Fernprozeduraufruf bewirkt den Abbruch aller begonnenen Aufträge. 2. Formatierungs-Fernprozeduraufrufe
Der obige Fernprozeduraufruf definiert ein Format mit den exakten Parametern, wie sie in dem Formatobjekt zu finden sind. Alle Parameter, die gleich NOT_ASSIGNED (nicht_ zugewiesen) sind, sind in der Definition nicht enthalten.
Der obige Fernprozeduraufruf definiert eine Box bzw. einen Kasten mit den exakten Parametern, wie sie im Boxobjekt zu finden sind. Alle Parameter, die gleich NOT_ASSIGNED (nicht_zugewiesen) sind, sind in der Definition nicht enthalten.
Der obige Fernprozeduraufruf modifiziert die Box, die mit dem im Boxobjekt spezifizierten Bezeichner übereinstimmt. Alle Parameter im Boxobjekt, die gleich NOT_ASSIGNED (nicht_zugewiesen) sind, werden nicht modifiziert.
Der obige Fernprozeduraufruf modifiziert die Box, die mit dem im Boxobjekt angegebenen Bezeichner übereinstimmt. Die Position der Box wird um die in x_Verschiebung und y_ Verschiebung spezifizierten Beträge verschoben. Alle Parameter im Boxobjekt, die gleich NOT_ASSIGNED (nicht_zugewiesen) sind, werden nicht modifiziert.
Der obige Fernprozeduraufruf modifiziert das Format, das mit dem im Formatobjekt angegebenen Bezeichner übereinstimmt. Alle Parameter im Formatobjekt, die gleich NOT_AS- SIGNED (nicht_zugewiesen) sind, werden nicht modifiziert.
Der obige Fernprozeduraufruf löscht das letzte erfaßte Bild.
Der obige Fernprozeduraufruf löscht die Box mit einem Bezeichner, der mit dem des empfangenen Boxobjekts übereinstimmt. DEF ist ein wahlfreier Parameter und veranlaßt, wenn er auf TRUE gesetzt ist, eine Verzögerung des Auftrags und seiner Verarbeitung im Hintergrund. Bei Nichtempfang wird DEF auf FALSE gesetzt. ALL ist ein wahlfreier Parameter und veranlaßt, wenn er auf TRUE gesetzt ist, das Löschen aller definierten Boxen. Bei Nichtempfang wird ALL auf FALSE gesetzt.
Der obige Fernprozeduraufruf löscht das Format mit einem Bezeichner, der mit dem des empfangenen Formatobjekts übereinstimmt. DEF ist ein wahlfreier Parameter und veranlaßt, wenn er auf TRUE gesetzt ist, eine Verzögerung des Auftrags und seiner Verarbeitung im Hintergrund. Bei Nichtempfang wird DEF auf FALSE gesetzt. ALL ist ein wahlfreier Parameter und veranlaßt, wenn er auf TRUE gesetzt ist, das Löschen aller definierten Formate. Bei Nichtempfang wird ALL auf FALSE gesetzt.
Der obige Fernprozeduraufruf löscht das Bild mit einem Bezeichner, der mit dem des empfangenen IMAGE-Objekts übereinstimmt. DEF ist ein wahlfreier Parameter und veranlaßt, wenn er auf TRUE gesetzt ist, eine Verzögerung des Auftrags und seiner Verarbeitung im Hintergrund. Bei Nichtempfang wird DEF auf FALSE gesetzt. ALL ist ein wahlfreier Parameter und veranlaßt, wenn er auf TRUE gesetzt ist, das Löschen aller definierten Bilder. Bei Nichtempfang wird ALL auf FALSE gesetzt.
Der obige Fernprozeduraufruf löscht alle Bilder, Boxen, Formate und Tabellen, die in dem Laserbilderzeuger definiert sind. DEF ist ein wahlfreier Parameter und veranlaßt, wenn er auf TRUE gesetzt ist, eine Verzögerung des Auftrags und dessen Verarbeitung im Hintergrund. Bei Nichtempfang wird DEF auf FALSE gesetzt.
Der obige Fernprozeduraufruf löscht alle mittels Festformatspeicher-Fernprozeduraufrufen gespeicherten Bilder. 3. Bildmanipulations-Fernprozeduraufrufe
Dieser Fernprozeduraufruf wird streng mit fester Formatierung angewandt. Dieser Fernprozeduraufruf erfaßt das nächste Bild und speichert es unter der nächsten verfügbaren festen Bildspeicheradresse. Die Adressen reichen von 1 bis N, wobei N die Formatangabe ist.
Dieser Fernprozeduraufruf wird streng mit fester Formatierung angewandt. Dieser Fernprozeduraufruf erfaßt das nächste Bild und speichert es unter der durch den Bezeichner angegebenen Adresse. Die Adressen reichen von 1 bis N, wobei N die Formatangabe ist.
Der obige Fernprozeduraufruf erfaßt das nächste Bild.
Die Rücksprung-Information bezüglich der Bildgröße wird in LI_response abgelegt.
Der obige Fernprozeduraufruf erfaßt das nächste Bild als Testbild. Die Rücksprung-Information bezüglich der Bildgröße wird in LI_response abgelegt.
Der obige Fernprozeduraufruf speichert den Text und den Bezeichner in dem STRING-Objekt. Dies ermöglicht, daß die Client-Komponente den Text zu beliebiger Zeit über den Bezeichner wiederaufruft. Die Rücksprung-Information bezüglich der String-Größe wird in LI_response abgelegt.
Der obige Fernprozeduraufruf überträgt das nächste Bild als Hintergrundauftrag. Die Rücksprung-Information bezüglich der Bildgröße ist verfügbar, sobald die Bildübertragung beendet ist.
Der obige Fernprozeduraufruf ordnet einen ausreichenden Bildspeicher zur Aufnahme des durch das IMAGE-Objekt beschriebenen Bildes zu. 4. Verfahrenskonfiguration / Zusands-Fernprozeduraufruf
Der obige Fernprozeduraufruf stellt die Abbildungsparameter für den Laserbilderzeuger ein. Alle auf NOT_ASSIGNED (nicht_zugewiesen) eingestellten Parameter bleiben unverändert. 5. Zustands-Fernprozeduraufrufe
Der obige Fernprozeduraufruf ruft die Abbildungsparameter für den Laserbilderzeuger ab.
Der obige Fernprozeduraufruf ruft die Abbildungsparameter mit fester Formatierung für den Laserbilderzeuger ab. Alle anderen Elemente im Parameterobjekt bleiben unverändert.
Der obige Fernprozeduraufruf ruft alle Speicherbedingungen des Laserbilderzeugers ab.
Der obige Fernprozeduraufruf ruft die Länge und Breite des Bildes ab, dessen Bezeichner mit dem im Bildobjekt angegebenen Bezeichner übereinstimmt. Alle Bildinformationen sind im Bildobjekt abgelegt.
Der obige Fernprozeduraufruf ruft den Zustand des Druckers ab, dessen Bezeichner mit dem im Druckerobjekt angegebenen Bezeichner übereinstimmt. Alle Druckerinformationen sind im Druckerobjekt abgelegt.
Der obige Fernprozeduraufruf ruft den Zustand des Auftrags ab, dessen Bezeichner mit dem im Job-Objekt angegebenen Bezeichner übereinstimmt. Alle Auftragsinformationen sind im Auftragsobjekt abgelegt.
Der obige Fernprozeduraufruf ruft den Zustand des Übertragungsauftrags ab dessen Bezeichner mit dem im Übertragungsauftrag-Objekt angegebenen Bezeichner übereinstimmt. Alle Übertragungsauftrag-Informationen sind im Übertragungsauftrag- Objekt abgelegt.
Der obige Fernprozeduraufruf ruft eine Folge von Bezeichnern der definierten Formate ab.
Der obige Fernprozeduraufruf ruft eine Folge von Bezeichnern der erfaßten Bilder ab.
Der obige Fernprozeduraufruf ruft eine Folge von Bezeichnern der definierten Kontrasttabellen ab.
Der obige Fernprozeduraufruf ruft eine Folge von Bezeichnern der definierten Farbkontrasttabellen ab.
Der obige Fernprozeduraufruf (RPC) ermöglicht der Client-Komponente, die Fehlersuchebene der Eingangsinterpretiererkomponente 22 einzustellen. Die Fehlersuchebenen sind NO_DEBUG (keine Fehlersuche), LOW_DEBUG (geringe Fehlersuche), MEDIUM_DEBUG (mittlere Fehlersuche) und HIGH_DEBUG (strenge Fehlersuche). Dieser Parameter beeinflußt die während der Fehlersuche angezeigten Informationen.
Ein Vorteil der Schnittstelle zur Ausgangsinterpretiererkomponente 24 besteht darin, daß jeder Fernprozeduraufruf ein ähnliches Objekt zurückgibt. Dieses Objekt wird am zweckmäßigsten als Laserbilderzeuger-Antwortobjekt bezeichnet, wie oben angegeben. Im Laserbilderzeuger-Antwortobjekt ist eine Fülle von Informationen bezüglich des Ergebnisses des Fernprozeduraufrufs enthalten. Der Client kann jedoch beschließen, nur die Informationen zu prüfen, die für seine Bedürfnisse relevant sind. Das Laserbilderzeuger-Antwortobjekt weist drei Felder auf. Das erste ist ein einfacher boolescher Wert mit der Bezeichnung Success (Erfolg). Der boolesche Wert gibt an, ob die mit dem Fernprozeduraufruf verbundene Anforderung ausgeführt wurde oder erfolglos war. Diese Information kann die Bedürfnisse der meisten Client-Komponenten erfüllen. Das zweite Feld, Success_Data (Erfolgsdaten), gibt etwaige Werte zurück, die von der Client-Komponente erwartet werden, wenn der Befehl erfolgreich war. Normalerweise gibt es keine Informationen zu einem erfolgreichen Befehl. Ein Beispiel einer bei einem erfolgreichen Befehl zurückgegebenen Information wäre jedoch die Bildgröße, die nach einem erfolgreichen Bildspeicherbefehl zurückgegeben wird. Das dritte Feld, Errors (Fehler), dient zur Erläuterung, weshalb der Fernprozeduraufruf fehlgeschlagen ist. Das Feld ist tatsächlich ein umfassendes Bitfeld von Fehlern, die der Laserbilderzeuger machen kann. Dieses Feld ist wiederum nur dann gültig, wenn Success den booleschen Wert FALSE (falsch) hat.
Der unten aufgeführte C++-Code beschreibt das Laserbilderzeuger-Antwortobjekt. Die Klasse definiert die nach der Ausgabe eines Befehls vom Laserbilderzeuger empfangene Antwort. Wenn der Befehl erfolgreich ausgeführt wurde, wird das SUCCESS-Flag auf TRUE (wahr) gesetzt. Etwaige Daten, die nach erfolgreicher Ausführung empfangen werden, werden in Success_Data gespeichert. War der Befehl erfolglos, dann wird das SUCCESS-Flag auf FALSE (falsch) gesetzt. Die Ursache für den Mißerfolg wird in der Struktur Failures (Fehler) gespeichert.
Die folgende Struktur enthält Daten, die von der Ausgangsabbildungsvorrichtung 18 (dem Laserbilderzeuger) zurückgegeben werden, wenn der Befehl korrekt ausgeführt wird. Folglich sind diese Daten nur dann gültig, wenn während der Ausführung keine Fehler aufgetreten sind.
Die eigentliche Basisklasse für die Ausgangsinterpretiererkomponente 24 kann in C++ wie folgt definiert werden:

D. Das Ausgangstreiber-Basisklassenprotokoll

Das Ausgangstreiber-Basisklassenprotokoll ist in dieser beispielhaften Ausführungsform praktisch identisch mit dem Eingangstreiber-Basisklassenprotokoll. Die Ausgangstreiberkomponente 26 stellt fünf Fernprozeduraufrufe für die Ausgangsinterpretiererkomponente 24 bereit. Mit den fünf Fernprozeduraufrufen kann die Ausgangsinterpretiererkomponente 24 direkt mit einer Ausgangsabbildungsvorrichtung 18 gekoppelt werden, wie z. B. mit einem Laserbilderzeuger. Nachstehend wird jeder der fünf Fernprozeduraufrufe beschrieben:
Der obige Fernprozeduraufruf empfängt von der Ausgangsinterpretiererkomponente 26 eine Meldung, die von der Ausgangsabbildungsvorrichtung 18 gesendet worden ist. Wieder bearbeitet die Ausgangsinterpretiererkomponente 26 alle Anforderungen zur Kommunikation mit der Ausgangsabbildungsvorrichtung.
Der obige Fernprozeduraufruf setzt den Zeitabschaltwert, den die Ausgangsinterpretiererkomponente 26 beim Senden an die Ausgangsabbildungsvorrichtung 18 verwenden sollte.
Der obige Fernprozeduraufruf gewährt der Ausgangsinterpretiererkomponente 26 Zugriff zu der asynchronen Routine der Client-Komponente, d. h. der Ausgangsinterpretiererkomponente 24. Der obige Fernprozeduraufruf dient zur Information der Client-Komponente über aufgetretene asynchrone Ereignisse. Das einzige Ereignis ist MSG_PENDING, das anzeigt, daß eine Meldung von der Ausgangsabbildungsvorrichtung 18 vollständig empfangen wurde und für die Ausgangsinterpretiererkomponente 24 bereitsteht.
Der obige Fernprozeduraufruf ermöglicht, daß die Client-Komponente die Fehlersuchebene für die Ausgangstreiberkomponente einstellt. Die Fehlersuchebenen sind NO_DEBUG (keine Fehlersuche), LOW_DEBUG (geringe Fehlersuche), MEDIUM_DEBUG (mittlere Fehlersuche) und HIGH_DEBUG (strenge Fehlersuche). Dieser Parameter beeinflußt die während der Fehlersuche angezeigten Informationen.
Wie oben festgestellt, gibt jeder Fernprozeduraufruf (RPC) einen von drei Rücksprungcodes zurück: (1) RPC_OK (Fernprozeduraufruf o.k.), (2) PORT_BUSY (Kanal besetzt) und (3) NO_MESSAGE (keine Meldung). Die Treiber-Rücksprungcodes können in C++ wie folgt definiert werden:
Das eigentliche Basisklassenprotokoll für die Ausgangstreiberkomponente 26 kann in C++ wie folgt definiert werden:

Claims

1. Softwaresystem zur Bildinformationskommunikation zwischen mindestens einer von mehreren verschiedenen Eingangsabbildungsvorrichtungen (12) und mindestens einer von mehreren verschiedenen Ausgangsabbildungsvorrichtungen (18), wobei das Softwaresystem aufweist:

eine oder mehrere Eingangstreiberkomponenten (20), wobei jede der Eingangstreiberkomponenten so konfiguriert ist, daß sie Bildinformationen von einer der Eingangsabbildungsvorrichtungen empfängt, wobei die Bildinformationen nach einem von mehreren verschiedenen Eingangstreiberprotokollen empfangen werden, wobei jedes der Eingangstreiberprotokolle spezifisch mit einer der Eingangsabbildungsvorrichtungen verbunden ist;

eine oder mehrere Eingangsinterpretiererkomponenten (22), wobei jede der Eingangsinterpretiererkomponenten so konfiguriert ist, daß sie erste Abbildungsanforderungen erzeugt, die auf den von einer der Eingangstreiberkomponenten empfangenen Bildinformationen basieren, wobei die ersten Abbildungsanforderungen nach einem von mehreren verschiedenen Eingangsinterpretiererprotokollen empfangen werden, wobei jedes der Eingangsinterpretiererprotokolle spezifisch mit einer der Eingangsabbildungsvorrichtungen verbunden ist;

eine oder mehrere Ausgangsinterpretiererkomponenten (24), wobei jede der Ausgangsinterpretiererkomponenten so konfiguriert ist, daß sie zweite Abbildungsanforderungen erzeugt, die auf den durch eine der Eingangsinterpretiererkomponenten erzeugten ersten Abbildungsanforderungen basieren, wobei die zweiten Abbildungsanforderungen nach einem von mehreren verschiedenen Ausgangsinterpretierprotokollen erzeugt werden, wobei jedes der Ausgangsinterpretierprotokolle spezifisch mit einer der Ausgangsabbildungsvorrichtungen verbunden ist;

eine oder mehrere Ausgangstreiberkomponenten (26), wobei jede der Ausgangstreiberkomponenten so konfiguriert ist, daß sie die durch eine der Ausgangsinterpretiererkomponenten erzeugten zweiten Abbildungsanforderungen zu einer der Ausgangsabbildungsvorrichtungen übermittelt, wobei die zweiten Abbildungsanforderungen nach einem von mehreren verschiedenen Ausgangstreiberprotokollen übermittelt werden, wobei jedes der Ausgangstreiberprotokolle spezifisch mit einer der Ausgangsabbildungsvorrichtungen verbunden ist; und

eine Schnittstellenablaufkomponente (28) zum Definieren einer oder mehrerer Kommunikationspipelines, wobei jede der Kommunikationspipelines eine der Eingangsabbildungsvorrichtungen, eine der Eingangstreiberkomponenten, eine der Eingangsinterpretiererkomponenten, eine der Ausgangsinterpretiererkomponenten, eine der Ausgangstreiberkomponenten und eine der Ausgangsabbildungsvorrichtungen kommunikativ miteinander verbindet.

2. Softwaresystem nach Anspruch 1, wobei jede der Eingangstreiberkomponenten eine erste Schnittstelle zum Übermitteln der Bildinformationen zu einer der Eingangsinterpretiererkomponenten nach einem ersten Basisklassenprotokoll aufweist, das generisch für jede der Eingangstreiberkomponenten ist und von jeder der Eingangsinterpretiererkomponenten verstanden wird;

jede der Eingangsinterpretiererkomponenten eine zweite Schnittstelle zum Übermitteln der ersten Abbildungsanforderungen zu einer der Ausgangsinterpretiererkomponenten nach einem zweiten Basisklassenprotokoll aufweist, das für jede der Eingangsinterpretiererkomponenten generisch ist und von jeder der Ausgangsinterpretiererkomponenten verstanden wird; und

jede der Ausgangsinterpretiererkomponenten eine dritte Schnittstelle zum Übermitteln der zweiten Abbildungsanforderungen zu einer der Ausgangstreiberkomponenten nach einem dritten Basisklassenprotokoll aufweist, das für jede der Ausgangsinterpretiererkomponenten generisch ist und von jeder der Ausgangstreiberkomponenten verstanden wird.

3. Softwaresystem nach Anspruch 2, wobei das erste Basisklassenprotokoll, das zweite Basisklassenprotokoll und das dritte Basisklassenprotokoll jeweils gemäß einer objektorientierten Hierarchie definiert sind.

4. Softwaresystem nach Anspruch 2, wobei:

jede der Ausgangstreiberkomponenten ferner so konfiguriert ist, daß sie erste Antworten auf die zweiten Abbildungsanforderungen von einer der Ausgangsabbildungsvorrichtungen empfängt, wobei die ersten Antworten nach einem der Ausgangstreiberprotokolle empfangen werden;

jede der Ausgangsinterpretiererkomponenten ferner so konfiguriert ist, daß sie zweite Antworten erzeugt, die auf den von einer der Ausgangstreiberkomponenten empfangenen ersten Antworten basieren, wobei die zweiten Antworten nach einem der Ausgangsinterpretierprotokolle erzeugt werden;

jede der Eingangsinterpretiererkomponenten ferner so konfiguriert ist, daß sie dritte Antworten erzeugt, die auf den durch eine der Ausgangsinterpretiererkomponenten erzeugten zweiten Antworten basieren, wobei die dritten Antworten nach einem der Eingangsinterpretiererprotokolle erzeugt werden; und

jede der Ausgangstreiberkomponenten ferner so konfiguriert ist, daß sie zweite Antworten auf die zweiten Abbildungsanforderungen erzeugt, die durch eine der Ausgangsinterpretiererkomponenten erzeugt werden, wobei die zweiten Antworten nach einem der Ausgangstreiberprotokolle erzeugt werden;

jede der Eingangstreiberkomponenten ferner so konfiguriert ist, daß sie die durch eine der Eingangsinterpretiererkomponenten erzeugten dritten Antworten zu einer der Eingangsabbildungsvorrichtungen übermittelt, wobei die dritten Antworten nach einem der Eingangstreiberprotokolle übermittelt werden; und

jede der durch die Schnittstellenablaufkomponente definierten Pipelines eine bidirektionale Pipeline ist, die eine der Eingangsabbildungsvorrichtungen, eine der Eingangstreiberkomponenten, eine der Eingangsinterpretiererkomponenten, eine der Ausgangsinterpretiererkomponenten, eine der Ausgangstreiberkomponenten und eine der Ausgangsabbildungsvorrichtungen für eine Kommunikation in zwei Richtungen zwischen einer der Eingangsabbildungsvorrichtungen und einer der Ausgangsabbildungsvorrichtungen kommunikativ miteinander verbindet.

5. Softwaresystem nach Anspruch 4, wobei:

jede der Ausgangstreiberkomponenten eine vierte Schnittstelle zum Übermitteln der ersten Antworten zu einer der Ausgangsinterpretiererkomponenten nach einem vierten Basisklassenprotokoll aufweist, das für jede der Ausgangstreiberkomponenten generisch ist und von jeder der Ausgangsinterpretiererkomponenten verstanden wird;

die dritte Schnittstelle jeder der Ausgangsinterpretiererkomponenten so konfiguriert ist, daß sie die zweite Antwort zu einer der Eingangsinterpretiererkomponenten nach dem dritten Basisklassenprotokoll übermittelt, das für jede der Ausgangsinterpretiererkomponenten generisch ist und von jeder der Eingangsinterpretiererkomponenten verstanden wird; und

die zweite Schnittstelle jeder der Eingangsinterpretiererkomponenten so konfiguriert ist, daß sie die erste Antwort zu einer der Eingangstreiberkomponenten nach dem zweiten Basisklassenprotokoll übermittelt, das für jede der Eingangsinterpretiererkomponenten generisch ist und von jeder der Eingangstreiberkomponenten verstanden wird.

6. Softwaresystem nach Anspruch 5, wobei mindestens eine der Eingangsabbildungsvorrichtungen eine medizinische Abbildungsvorrichtung und mindestens eine der Ausgangsabbildungsvorrichtungen einen Laserbilderzeuger aufweist.

7. Softwaresystem nach Anspruch 5, wobei die Schnittstellenablaufkomponente jede der Pipelines gemäß einer Client- Server-Beziehung definiert, so daß jede der Eingangsinterpretiererkomponenten ein Client einer der Eingangstreiberkomponenten ist, jede der Eingangsinterpretiererkomponenten ein Client einer der Ausgangsinterpretiererkomponenten ist, jede der Ausgangsinterpretiererkomponenten ein Client einer der Ausgangstreiberkomponenten ist und die Schnittstellenablaufkomponente ein Client jeder der Eingangstreiberkomponenten, jeder der Eingangsinterpretiererkomponenten, jeder der Ausgangsinterpretiererkomponenten und jeder der Ausgangstreiberkomponenten ist.

8. Softwaresystem nach Anspruch 7, wobei die Kommunikation zwischen den Eingangsinterpretiererkomponenten, den Eingangstreiberkomponenten und den Ausgangsinterpretiererkompo nenten durch Fernprozeduraufrufe erfolgt, die durch die Eingangsinterpretiererkomponenten erzeugt und durch die Eingangstreiberkomponenten und die Ausgangsinterpretiererkomponenten ausgeführt werden, wobei die Kommunikation zwischen den Ausgangsinterpretiererkomponenten und den Ausgangstreiberkomponenten durch Fernprozeduraufrufe erfolgt, die durch die Ausgangsinterpretiererkomponenten erzeugt und durch die Ausgangstreiberkomponenten ausgeführt werden, und wobei die Kommunikation zwischen der Schnittstellenablaufkomponente, den Eingangstreiberkomponenten, den Eingangsinterpretiererkomponenten, den Ausgangsinterpretiererkomponenten und den Ausgangstreiberkomponenten durch Fernprozeduraufrufe erfolgt, die durch die Schnittstellenablaufkomponente erzeugt und durch die Eingangstreiberkomponenten, die Eingangsinterpretiererkomponenten, die Ausgangsinterpretiererkomponenten und die Ausgangstreiberkomponenten ausgeführt werden.

9. Softwaresystem nach Anspruch 1, wobei das Softwaresystem in einem Bildverarbeitungssystem enthalten ist.