DE60030329T2

DE60030329T2 - Steuerung und Beobachtung von physikalischen Geräten, Einrichtung und Verfahren durch eine Vielzahl von Benutzern über Rechnernetzwerke

Info

Publication number: DE60030329T2
Application number: DE60030329T
Authority: DE
Inventors: Lambertus Atherton HESSELINK; Dharmarus Mountain View RIZAL; S. Eric Mountain View BJORNSON
Original assignee: Senvid Inc
Current assignee: Western Digital Technologies Inc
Priority date: 1999-12-02
Filing date: 2000-12-01
Publication date: 2007-10-11
Anticipated expiration: 2020-12-02
Also published as: AU1811901A; WO2001040961A8; WO2001040961A1; EP1247190B1; DE60030329D1; EP1247190A4; JP2003517229A; US6732158B1; CA2393171A1; US7467187B2; US6499054B1; EP1247190A1; JP4549601B2; CA2393171C; ATE337670T1; US20030051006A1

Description

GEBIET DER ERFINDUNG
Die vorliegende Erfindung betrifft im weitesten Sinne Telekommunikation und die Fernbetätigung von physikalischen Prozessen in einem Labor. Insbesondere betrifft die vorliegende Erfindung die Steuerung von physikalischen Prozessen über ein Computernetzwerk.
STAND DER TECHNIK
Fernlernen ist ein sich rasant entwickelndes Gebiet, dessen Triebfeder die Internetrevolution ist. Eine Schlüsselkomponente gegenwärtiger Fernlernimplementierungen in Wissenschaft und Technik fehlt jedoch: Laborversuche. Versuchsdemonstrationen im Unterricht verstärken die Lernerfahrung und verleihen komplexen theoretischen Konzepten Realitätsbezogenheit. Die Kosten stellen jedoch ein Hindernis dar. Vielen Universitäten, Hochschulen, Mittelschulen und Volksschulen fehlen die nötigen Ressourcen, um Laborversuche durchzuführen. Abgesehen davon, dass Gerätekosten einen wesentlichen Faktor darstellen, sind auch Arbeitskräfte in Zusammenhang mit der Stellenbesetzung eines Labors relativ hoch. Ohne eine Laborkomponente sind Fernlernprogramme, verglichen mit klassischen Unterrichtsmethoden, diesen nicht nur unterlegen, sondern können auch die Grundanerkennungskriterien nicht erfüllen. Klassische Laborlehrprogramme sind teuer, da gut ausgebildetes Personal erforderlich ist, um diese zu konzipieren, durchzuführen und instand zu halten, während seltene Verwendung zu hohen Fixkosten führen. Folglich stellt der Laborversuche erfordernde Wissenschaftsunterricht ein deutliches Hindernis für Fernlernanwendungen dar.
Eines der überzeugendsten Merkmale eines globalen Computernetzwerks, wie z.B. des Internets, ist die Fähigkeit, mehreren Benutzern einen Viele-zu-Einem-Zugriff auf Ressourcen bereitzustellen. Ein Labor ist eine Art der Ressource, die ohne weiteres von vielen benutzt werden kann, und es gibt weitaus mehr Menschen auf der Welt, die Zugang zu einem Computer mit Internetanschluss als zu einem Labor haben. Zur Durchführung physikalischer Prozesse in einem Laborumfeld müssen den Lernenden oder anderen Benutzern jedoch Rückmeldungen aus den physikalischen Prozessen, wie z.B. Gerätebedienung sowie Datenerhebung, mit minimaler Verzögerung bereitgestellt werden. Folglich müssen Eindruck und Atmosphäre eines Labors genau reproduziert werden, wenn ein Labor über Internet zugänglich gemacht werden soll. Ein Laborbenutzer muss nicht nur Daten sammeln und rasch analysieren, um physikalische Prozesse in einem Labor zu manipulieren, sondern muss auch sehen können, was während des Vorgangs passiert.
Das Transportieren von Videodaten in Echtzeit über das Internet stellt für Anwendungen, wie z.B. das Onlinelabor, ein Haupthindernis dar. Das Gesamt-Volumen an Daten, das gesendet werden muss wird häufig Verzögerungen unterzogen, wodurch die Umsetzung von Online-Laborversuchen erschwert wird, wenn nicht sogar unmöglich gemacht wird.
Demnach besteht die Erfordernis nach einem System und einem Verfahren, das es Benutzern ermöglicht, physikalische Prozesse in entfernten Labors über ein Computernetzwerk zu manipulieren und Daten- sowie Videorückmeldungen während des physikalischen Vorgangs mit minimaler Verzögerung bereitzustellen.
Goldberg et al. beschreiben in "Beyond the Web: manipulating the real world", Computer Networks and ISDN Systems 28, 209-219 (1995) eine WWW-Seite, die öffentlichen Zugriff auf einen ferngesteuerten Roboter bereitstellt. Mit einem Random-Token-System erfasst das System jeden Benutzer, wenn dieser die Oberfläche benutzt und erzeugt geeignete HTML-Dokumente. Zum Betreiben des Roboters muss der Anwender die Information zur Benutzung des Steuerungspults lesen und einen Test der Berechtigungsstufe 1 durchführen, um ein Passwort zu erhalten. Der Roboter kann jeweils nur von einer Person betrieben werden.
Shen et al. beschreiben in "Conducting Laboratory Experiments over the Internet", IEEE Transactions on Education, Bd. 42, Nr. 3 (August 1999) ein interaktives Onlinelabor für Fernerziehung mit dem Titel Automated Internet Measurement Laboratory (AIM-Lab), das vom Internet und dem World Wide Web (WWW) Gebrauch macht.
Ein Lehrender kann sämtliche damit in Zusammenhang stehende Benutzerprozesse überwachen. Befehle und Daten werden in für den jeweiligen Benutzer dedizierten Dokumentfenstern gespeichert. Versuchserfordernisse werden an den Betreiber des zu bedienenden Geräts in Empfangsreihenfolge gesendet und die daraus hervorgehenden Daten demgemäß zurückgesendet.
Scharf et al. beschreiben in "Using Mosaic for Remote Test System Control Supports Distributed Engineering",
http://archive.ncsa.uiuc.edu/SDG/IT94/Proceedings/CSCW/scharf.html,
Oktober (1994) einen Fernzugriff auf Testgeräte, wobei ein Gateway-Server einen HTTP-Zugriff auf ein Elektronenstrahltestsystem ermöglicht, welches chipinterne Bilderzeugungs- und Messparameter, Schwenken und Zoomen des Bildes selbst und Untersuchungen des Verhaltens eines integrierten Chips gestattet. Das System stellt eine Oberfläche bereit, die die Steuerung eines Testsystems durch einen Fernbenutzer mithilfe eines CGI-Servers ermöglicht. Echtzeitbilderzeugung wird dem Benutzer nicht bereitgestellt. Nur jeweils ein Benutzer kann die Testgeräte steuern. Alle anderen Benutzer können lediglich eine Leseanforderung ausstellen, um die neuesten Hardware-Einstellungen, Bild- und Schwingungsverläufe zu erhalten.
Arpaia et al. beschreiben in "A Measurement Laboratory on Geographic Network for Remote Test Experiments", IEEE Instrumentation and Technology Conference, St. Paul, MN, USA, (Mai 18-21, 1998) ein Fernlehrlabor, wo Studenten über ein geographisches Netzwerk (WWW) Zugriff auf automatische Messeinstellungen und Geräte haben und echte Versuche direkt ausführen können. Die Erfordernisse der Benutzer werden von einem allgemeinen Server (GS) verwaltet, der protokollierte Benutzeranforderungen nach dem FIFO-Verfahren bearbeitet.
ZUSAMMENFASSUNG DER ERFINDUNG
In einem ersten Aspekt stellt die vorliegende Erfindung ein System für den Fernzugriff und die Fernbetätigung einer elektronischen Vorrichtung gemäß Anspruch 1 bereit. In einem weiteren Aspekt stellt die vorliegende Erfindung ein Verfahren für den Fernzugriff und die Fernbetätigung einer elektronischen Vorrichtung gemäß Anspruch 4 bereit.
Die vorliegende Erfindung ermöglicht vielen Benutzern, die sich an verschiedenen Orten aufhalten, über Computernetzwerke, wie z.B. das Internet oder ein privates Intranet, auf physikalische Prozesse oder Umgebungen zuzugreifen, diese zu beobachten, zu steuern und zu manipulieren, entweder synchron oder asynchron. Durch das Bereitstellen einer einzigartigen Informationsverteilungsmöglichkeit bringt diese Technologie daher ein neues Verfahren zum Teilen von Informationen mit sich, welches in einer Reihe von Aktivitäten, wie z.B. Fernlernen, Medizinpraxis, Ölexploration, Arzneimittelentwicklung, Chemie, Physik, Schadstoffüberwachung, Wetterdatenerhebung und vielen anderen Gebieten, in denen Geräte Daten über physikalische und andere Prozesse bereitstellen, angewandt werden kann.
Benutzer, die an Computernetzwerke, wie z.B. das Internet, angeschlossen sind, können Tätigkeiten, wie z.B. Steuern von Geräten und Prozessen, in Echtzeit durchführen. Durch das Reservieren von Laborsitzungen mittels Online-Planung können Benutzer während der geplanten Zeiträume sicheren und exklusiven Zugang zum Versuch haben. Merkmale der Erfindung umfassen Folgende: Echtzeitvideo und Datenstrom. Mit diesem Merkmal kann der Benutzer einen physikalischen Aufbau und den Zustand eines Versuchs oder der Umgebung visuell überwachen. Ein weiteres Merkmal ist die Echtzeit-Zweiwegkommunikation mit den Gerätesystemen. Benutzer können Laborgeräte direkt steuern und Rückmeldungen in Bezug auf Eingabebefehle in Echtzeit erhalten. Mit einem weiteren Merkmal können rechentechnische Analysen in Echtzeit durchgeführt werden. In die Datenbank können nicht nur Messdaten aufgenommen werden; rechentechnische Analysen, nämlich Statistiktransformationen, können erzeugt und als die erhobene Messung angezeigt werden. In einem weiteren Merkmal der vorliegenden Erfindung wird eine Benutzeroberfläche bereitgestellt, die ein Online-Benutzernotebook inkludiert. Das Notebook stellt Benutzern die Oberfläche bereit, um Benutzerdaten, wie z.B. gesammelte Daten, Laborparameter, Aufgabenlisten, persönliche Notizen, etc. zu verwalten.
KURZE BESCHREIBUNG DER ZEICHNUNGEN
Die vorherigen Aspekte und viele damit in Zusammenhang stehende Vorteile der vorliegenden Erfindung ergeben sich aus nachstehender detaillierter Beschreibung sowie den beigefügten Zeichnungen, worin:
1A eine graphische Darstellung des in der vorliegenden Erfindung verwendeten Computernetzwerks ist;
1B eine graphische Darstellung der Systemarchitektur der vorliegenden Erfindung in Blockform ist;
2 das in vorliegender Erfindung verwendete DNP-Paketformat veranschaulicht;
3 ein von einem Client-Prozess an einen Laborserver gesendete Paket zeigt;
4 ein vom Laborserver 112 an einen Client-Prozess gesendetes Antwortpaket zeigt;
5 ein Flussdiagramm ist, das die logische Abfolge an Schritten für den Laborserver zur Übertragung der Rohdaten aus physikalischen Prozessen zur Berechnung der Ergebnisse, bezogen auf die rechentechnische Analyse der Rohdaten veranschaulicht;
6 ein Flussdiagramm ist, das die logische Abfolge von Schritten für den Laborserver veranschaulicht, um Client-Befehle zu interpretieren, Befehle auszuführen und Antworten zu generieren;
7 ein Flussdiagramm ist, das den Grundbetrieb des Verbindungsmonitors veranschaulicht;
8 mehrere Routing-Modi zeigt, die vom Verbindungsserver durchgeführt werden können;
9 ein Flussdiagramm ist, das den Grundbetrieb der Verbindungssteuerung zeigt;
10 ein Flussdiagramm ist, das die Client-DNP-Paket-Weiterverarbeitung zeigt;
11 eine graphische Darstellung eines zweidimensionalen Satzes an DCT-Komponenten ist;
12 ein Flussdiagramm ist, das die logische Abfolge von Schritten veranschaulicht, die von einem Server zur Durchführung von Kodierungsprozessen ausgeführt werden; und
13 ein Flussdiagramm ist, das die logische Abfolge von Schritten veranschaulicht, die vom Client-Prozess zur Durchführung von Kodierungsprozessen ausgeführt werden.
DETAILLIERTE BESCHREIBUNG
1A zeigt einen Computer 10, der über ein Computernetzwerk, wie z.B. Internet 50, mit einem Computer 60 verbunden ist, welcher Vorrichtungen in einem Labor manipuliert. Die Computer 10, 60 können von herkömmlichem Design sein mit integriertem Prozessorchassis unter Verwendung einer zentralen Einheit (CPU), verschiedener Speicher und unterstützender integrierter Schaltung. An den Prozessor sind eine Tastatur 12 und ein Monitor 16 angeschlossen. Ein Benutzer kann den Computer 10 über die Tastatur 12 oder Maus 18 steuern, um einen Cursor zu manipulieren, der auf dem Bildschirm des Monitors 14 bewegt wird, um eine Auswahl an Programmen zu treffen, die vom Computer 10 ausgeführt werden. Das Diskettenlaufwerk 20 und die Festplatte 22 können auch in den Computern 10, 60 eingebaut sein.
Obwohl in 1 ein Computer vom Desktop-Typ dargestellt ist, können auch andere Arten von Computern, wie z.B. Arbeitsplatzrechner, Laptops, Palmtops, nicht programmierbare Datenstationen oder jeglicher anderer Computer, der zur Kommunikation mit anderen Computern fähig ist, in Zusammenhang mit vorliegender Erfindung verwendet werden.
Die Computer 10, 60 können über das Computernetzwerk 50 über Modem und Telefonleitung kommunizieren. Ein Betriebssystem sowie ein Browserprogramm können ebenfalls in den Computern 10, 60 installiert sein, sodass ein Benutzer Zugang zum Labor hat. Andere Medien können jedoch ebenso verwendet werden, wie z.B. eine Direktverbindung oder Hochgeschwindigkeitsdatenleitung. Das Computernetzwerk 50 kann, wie oben beschrieben, ein großes und komplexes System sein, das eine große Anzahl an Knoten und Komponenten aufweisen kann.
Der Computer 60 befindet sich in einem Labor, in welchem physikalische Prozesse durchgeführt werden sollen. Zur Veranschaulichung wird hierin der Betrieb eines Laser- und optischen Geräts beschrieben, wobei jedoch klar ist, dass andere Typen physikalischer Prozesse in Zusammenhang mit vorliegender Erfindung verwendet werden können. Eine Schnittstelle 62 wird mit dem Prozessor in Computer 60 verbunden, wodurch es einem Benutzer ermöglicht wird, den Laser 64 zu steuern. Der Strahl des Lasers 64 kann durch verschiedene optische Geräte 66 geleitet werden, der auf Tabelle 68 mittels Schnittstelle 62 eingestellt werden kann. In einer Ausführungsform der vorliegenden Erfindung kann die Schnittstelle 62 eine PCI-GPIB-Karte zur Steuerung und Überwachung von Laser 64 verwenden. Zur Erfassung von Bildern des Laserstrahls, die vom optischen Gerät 66 verarbeitet wurden, kann ein CCD-Detektor, der digitalisierte Bilder an eine IMAQ-PCI-1424-Karte überträgt, verwendet werden. Das optische Gerät 66 kann mechanisch durch motorisierte Plattformen, an welchen das Gerät befestigt ist, eingestellt und ausgerichtet werden. Zur Darstellung von Echtzeitbildern der Prozesse und der Geräte kann eine IMAQ-PCI-1408-Karte verwendet werden, um das Analogvideosignal aus Kamera 70 zu digitalisieren. Die Bewegung der Kamera 70 kann mittels eines Bewegungssteuerungssystems gesteuert werden, das mit einer Softwareanwendung, wie z.B. LabView, ver fügbar ist, das auf Computer 60 gespeichert und damit ausgeführt werden kann. Die Kamera 70 ist mit einem Framegrabber 72 ausgestattet, um Videorückmeldungen des physikalischen Prozesses bereitzustellen, und wird mit dem Video-Server 72 gesteuert, der auf dem Prozessor von Computer 60 ausgeführt werden kann. Die Systemsoftware auf Computer 60 kann auch IMAQ-Vision für G umfassen, die Bildverarbeitungsbibliotheken, wie z.B. eine schnelle Fourier-Transformations-(FFT-)Routine, bereitstellt, um die Entwicklung von Echtzeit-Datenanalysesoftware zu beschleunigen.
Bezugnehmend auf 1B integriert die Systemarchitektur 100 Hardware und Software, die Zweiwegkommunikation zwischen physikalischen Prozessen 110 und Online-Benutzern über die Computernetzwerke erleichtert. Das System kann, hinsichtlich Funktionalität in mehrere Prozesse unterteilt werden: physikalische Prozesse 110, Laborserver 112, Verbindungsserver 114, Clients 118, Datenbankserver 120. Diese Prozesse können als Softwareprogramme installiert sein, die in Rechnervorrichtungen, wie z.B. Computern, ausgeführt werden. Wie hierin verwendet, werden physikalische Prozesse 110 als physikalische, biologische und/oder chemische Prozesse oder Phänomene definiert, die mit elektronischen Vorrichtungen, wie z.B. Detektoren, Sensoren, Motoren, Spannungsquellen, etc. an den verschiedenen Schnittstellen, wie z.B. GPIB, RS-232, PCI, USB, Ethernet, etc., an jenen Geräten detektiert, gemessen, quantifiziert und/oder gesteuert werden können, die die physikalischen Prozesse 110 überwachen und steuern sowie mit dem Computer 60, der den Laborserver-Prozess 112 steuert, kommunizieren.
Daten aus den physikalischen Prozessen 110 werden vom Laborserver 112 zur Speicherung in die Datenbank über den Datenbankserver 120 und/oder zur Verteilung an die Clients 118 über den Verbindungsserver 114 erfasst. Vor Versenden der Daten kann der Laborserver 112 auch eine Analyse und Transformation der Daten, wie z.B. Statistiken und FFT-Berechnungen durchführen. Der Laborserver 112 empfängt auch Daten von den Clients 118, wie z.B. Steuerbefehle durch den Verbindungsserver 114. Nach Analyse dieser Befehle, leitet der Laborserver 112 die Befehle anschließend an die elektronischen Vorrichtungen oder Geräte (nämlich Laser, Motoren, Detektoren, etc.). Wie in 1B gezeigt, gibt es mehrfache physikalische Prozesse 110, nämlich den physikalischen Prozess 110-1, den physikalischen Prozess 110-12 sowie die mehrfachen Laborserver 112-1, 112-2.
Der Verbindungsserver 114 dient als Verteiler von Daten, die Informationen von Datenquellen an geeignete Ziele annimmt, verifiziert und leitet. Der Verbindungsserver 114 unterstützt Duplex-Punkt-zu-Punkt- und Punkt-zu-Mehrpunkt-Datenübertragungen zwischen den Clients 118, dem Laborserver 112 und dem Datenbankserver 120. Nachstehend sind mehrere Übertragungsmodi angeführt. Zudem überwacht der Verbindungsserver 114 über den gesamten Prozess hindurch auch den Status der Netzwerkverbindungen.
Die Client-Prozesse 118 stellen Benutzeroberflächen (UI) für Benutzer-Eingabe und Ausgabefunktionen bereit. Die Client-Presse 118 werden als Softwareprogramme installiert, die auf Client-Rechnervorrichtungen, wie z.B. Desktop-Computern, betrieben werden können. Der Client baut auch Zweiwegkommunikation mit dem Verbindungsserver 114 auf. Daten aus dem Verbindungsserver 114 werden dekodiert und gemäß den assoziierten Formaten, wie z.B. Video, Grafik, LED-Anzeigen, etc., angezeigt.
In einer bevorzugten Ausführungsform wird Kommunikation zwischen den obigen Prozessen unter Verwendung einer allgemeinen Sprache, wie z.B. Data Network Protocol (DNP) durchgeführt. Neben dem Transport verschiedener Datentypen, führt DNP auch Netzwerk- und Kommunikations-bezogene Nachrichten zwischen verschiedenen Prozessen durch. Das DNP-Paketformat wird ebenfalls in nachfolgenden Abschnitten besprochen.
Der Laborserver 112 kann sich am Ort des physikalischen Prozesses 110 befinden, um über direkte Steuerung des physikalischen Prozesses vor Ort zu verfügen. Der Laborserver 112 ist jener Prozess, der Daten aus dem physikalischen Prozess 110 überträgt und den physikalischen Prozess 110, bezogen auf Anfragen von Clients 118, steuert. Der Laborserver 112 kann als multithreading-fähige Software installiert werden, die Kommunikationsfunktionen über Computernetzwerke, wie z.B. das Inter net 116, durchführt. Zur Bereitstellung universeller und verlässlicher Kommunikation können sämtliche Daten unter Verwendung von Netzwerkprotokollen auf Standardverbindungsbasis, wie z.B. Transmission Control Protocol/Internet Protocol (TCP/IP) transportiert werden. Jede der Verbindungen (in diesem Fall zwischen dem Laborserverprozess 112, dem Verbindungsserverprozess 114 und den Clients 118) wird herkömmlich als Socket bezeichnet, der aus einer Netzwerk- oder IP-Adresse und einer Anschlussnummer besteht. Die Daten selbst und andere Kommunikationsnachrichten werden in einem Format kodiert, das als Data Network Protocol (DNP) bezeichnet wird. Im OSI-Netzwerk-Modell kann DNP als Anwendungsschichtprotokoll, wie HTTP und FTP, angesehen werden. Das einzigartige DNP-Design stellt eine herkömmliche Sprache zwischen verschiedenen Prozessen bereit, die gemeinschaftliche Umgebungen zwischen mehrfachen Benutzern über das Internet ermöglicht.
DNP ist dafür vorgesehen, verschiedene Typen digitaler Daten, wie z.B. Float-, Ganzzahl-, boolesche-, Video- und Felddaten, durchzuführen. Daten werden mit DNP in eine Informationsentität kodiert, die als Paket bezeichnet wird, welches zwei Hauptabschnitte aufweist: den Verwaltungsdatenabschnitt 205 und den Anweisungsabschnitt 225. Bezugnehmend auf 2 wird das DNP-Paketformat veranschaulicht. Der Verwaltungsdatenabschnitt 205 kann die folgenden Felder mit festgelegter Größe enthalten:
Paketgröße 210: die Länge des gesamten Pakets, normalerweise in Byte-Wörtern (8-Bit-Einheiten).
Ziel-ID 212: kann Client-ID, Laborserver-ID, Verbindungsserver-ID, Sämtliche-Clients-Gruppen-ID, Sämtliche-Clients-und-Laborserver-Gruppen-ID oder Verbindungsservergruppen-ID enthalten, wohin das Paket verschickt wird.
Quellen-ID 214: kann Client-ID, Laborserver-ID oder Verbindungsserver-ID enthalten, woher das Paket stammt.
Anweisungsnummer 216: enthält die Zahl der Anweisungen nach dem Datenverwaltungsabschnitt 205. Beispielsweise liegen in 2 die N-Anweisungen vor.
Die Anweisungsabschnitt 225 kann eine Reihe von Anweisungen enthalten. Jede der Anweisungen kann ein spezifischer Befehl oder eine Anforderung sein, der/die folgende Felder enthält.
Komponenten-ID 230: Identifikationsnummer der/des spezifischen Vorrichtung/spezifischen Geräts für die Benutzerschnittstellenkomponente.
Komponenten-ID 232: Identifikationsnummer des/der spezifischen durchzuführenden Befehls/Anforderung.
Befehlswert 234: Parameterwerte, die dazu verwendet werden, die Befehle oder Anforderungen auszuführen. Bezogen auf den/die geforderte(n) Befehl/Anordnung, kann der Datentyp herkömmlicher Werte variieren (z.B. Float-, Ganzzahl-, Video- und Felddaten). Folglich weist dieses Feld unterschiedliche Größen auf. Sowohl Sender als auch Empfänger der Anforderung können eine Nachschlagliste von Datentypen in Zusammenhang mit den Komponenten-ID und Befehls-ID aufweisen. Folglich muss die Information über den Datentyp nicht im Paket selbst enthalten sein. Der Anweisungsabschnitt kann vergrößert werden, um die Komponenten-ID, Befehls-ID und Befehlwerte 252–262 zu enthalten. 3 zeigt ein Beispielspaket, das von einem Client 118 an einen Laborserver 112 geschickt wurde, welches eine Anforderung zur Änderung des Stromwerts eines Lasergeräts auf 45,4 mA darstellt. Im Verwaltungsdatenabschnitt 305 gibt es einen Paketgrößenabschnitt 302, einen Laborserver-ID-Abschnitt 304 und einen Client-ID-Abschnitt 306. Im Anweisungsabschnitt 315 gibt es einen Laser-ID-Abschnitt 320, einen Stromwertänderungsabschnitt 322 und die Ziel-Milliampere 45,4 in Abschnitt 324.
4 zeigt ein typisches Antwortpaket aus dem Laborserver 112 an sämtliche Clients 118, um zwei ihrer Benutzeroberflächenkomponenten zu aktualisieren: eine Grafik- und Nachrichtentafel-Anzeige mit einem Wert von 45,4 und eine Nachricht im Nachrichtenabschnitt 456, die Folgendermaßen lautet: "Ihr Befehl wurde erfolgreich ausgeführt."
Der Laborserver verfügt über zwei Hauptfunktionen: Daten der physikalischen Prozesse 110 zu übertragen; und Anforderungen und allgemein assoziierte Antworten von Clients durchzuführen. Damit Clients 118 mit den gegenwärtigen Zuständen der physikalischen Prozesse 110 auf dem Laufenden gehalten werden, kann der Laborserver 112 Informationen übertragen, die direkt aus den physikalischen Prozessen 110 erfasst wurden. Daten aus den physikalischen Prozessen 110, die im DNP-Paket kodiert sind, werden zur Verteilung an den Verbindungsserver 114 übertragen. Anschließend kann der Verbindungsserver den Datenverwaltungsabschnitt des übertragenen DNP-Pakets überprüfen und das Paket an die geeigneten Ziele weiterleiten. Details hinsichtlich des Routing-Algorithmus im Verbindungsserver sind nachstehend besprochen.
Sensoren, Detektoren und andere Messgeräte detektieren und/oder messen verschiedene physikalische Phänomene (nämlich elektrische Felder, elektromagnetische Strahlung, Temperatur, Druck, etc.) und senden diese Information an den Laborserver 112. Der Laborserver 112, der eine Netzwerkverbindung mit dem Verbindungsserver 114 hergestellt hat, kann die empfangene Information oder deren errechnete Analyse anschließend in den Anweisungsabschnitt des DNP-Pakets platzieren. Dieser Prozess kann wiederholt werden, wenn es erforderlich ist, dass mehr als eine Anweisung verschickt werden muss. Nachdem sämtliche Anweisungen im Anweisungsabschnitt des DNP-Pakets aufgezeichnet worden sind, können auch die entsprechenden Verwaltungsdatenabschnitte aufgebaut werden. Nachdem das DNP-Paket vervollständigt ist, kann dieses an den Verbindungsserver 114 gesendet werden.
Bezugnehmend auf 5, kann der Laborserver 112 die Rohdaten aus den physikalischen Prozessen 110 zu Berechnung der Ergebnisse bezogen auf die Rechneranalyse der Rohdaten übertragen. In manchen Fällen werden Daten aus den physikalischen Prozessen 110 für wissenschaftliche Visualisierungen, statistische Analysen oder Datenkomprimierung analysiert. Rohvideodaten aus dem physikalischen Prozess werden beispielsweise sowohl hinsichtlich räumlicher und zeitlicher Redundanz analysiert. Nach Durchführung eines Komprimierungsalgorithmus wird das komprimierte Format der Videodaten im Anweisungsabschnitt des DNP-Pakets aufgezeichnet. Videokomprimierung, die sich für diese Anwendung eignet, ist nachstehend be schrieben. Damit die Clients ein kontinuierliches Informations-Update erhalten, kann der gesamte Prozess in 5 in regelmäßigen Abständen wiederholt werden. Die Wiederholungsdauer für diesen Prozess kann gemäß der jeweiligen Anwendung angepasst werden. Bei Schritt 502 erhält der Laborserver 112 Daten aus dem physikalischen Prozess 110. Die Steuerung kann auf optionalem Schritt 504 fortfahren, bei dem der Laborserver 112 Rechneranalysen erstellt. Die Steuerung geht auf Schritt 506 weiter, bei dem eine Tabelle vom Nachschlagtyp konstruiert wird. Die Steuerung geht auf Schritt 508 weiter, bei dem Daten in den Anweisungsabschnitten des DNP-Pakets aufgezeichnet werden. Dies kann Teil einer Iterationsschleife sein, bei der die Steuerung auf Schritt 502 zurückkehrt. Die Steuerung kann auch aus Schritt 508 auf Schritt 510 weitergehen, bei dem das DNP-Paket auf den Verwaltungsdatenabschnitt aufgezeichnet wird. Die Steuerung geht auf Schritt 512 weiter, bei dem das DNP-Paket an den Verbindungsserver 114 geschickt wird.
Eine weitere Funktion des Laborservers 112 ist die Verarbeitung von Clients-Anforderungen und die Erzeugung assoziierter Antworten. Der Laborserver 112 kann ein DNP-Paket aus dem Verbindungsserver 114 erhalten, der die Anforderungen von Clients für Anweisungen enthält. Es liegt in der Verantwortlichkeit des Laborservers 112, diese Anweisungen zu interpretieren, die Befehle auszuführen und Antworten zu generieren. Dieser Prozess ist in 6 beschrieben. Die Steuerung beginnt in Schritt 520, bei dem der Laborserver 112 darauf wartet, dass das DNP-Paket vom Verbindungsserver 114 empfangen wird. Nach Weiterschreiten auf Schritt 522 wird der Verwaltungsdatenabschnitt des DNP-Pakets gelesen. Die Steuerung fährt mit 526 fort, bei dem der Laborserver 112 die Anforderung/Anweisung durch Aufrufen von Geräte-/Anweisungs-Treibern ausführt. Die Steuerung fährt mit Schritt 528 fort, bei dem der Laborserver 112 Antwortdaten im Anweisungsabschnitt des DNP-Pakets aufzeichnet. Von Schritt 528 aus kann die Steuerung auf Schritt 524 in einer Itrationsschleife gemäß der Anzahl an Anweisungen zurückspringen; die Steuerung kann auch auf Schritt 530 weitergehen, bei dem das DNP-Paket in den Verwaltungsdatenabschnitt eingeschrieben wird. Die Steuerung geht auf Schritt 532 weiter, bei dem ein Antwort-DNP-Paket an den Verbindungsserver 114 gesendet wird.
Die Ausführung von Clients-Anweisungen kann das Aufrufen bestimmter Softwaretreiber beinhalten, die Befehle an Geräte über die verbundenen Computerschnittstellen, wie z.B. GPIB, RS-232, USB, Ethernet, etc., senden. Die Anforderung kann auch Befehle hinsichtlich Informationsmanagement, wie z.B. Aufzeichnen der Client-Anforderungen, Speichern erfasster Werte aus Geräten und Abfragen zuvor erfasster Informationen, enthalten. Wenn es sich um Informationsmanagement handelt, kann der Laborserver 112 direkt mit den fokalen oder entfernten Datenbankservern mit Standarddatenbanktreibern, wie z.B. ODBC oder JDCB, wechselwirken.
Im Gegensatz zu Übertragungsfunktionen, die DNP-Pakete gegebenenfalls kontinuierliche an Clients senden, generiert diese Funktion des Laborservers 112 nur dann Antworten, wenn Client-Anforderungen erhalten werden. Wenn der Laborserver 112 in einem Softwareprogramm vorliegt, kann diese Funktion in einem getrennten Thread zur parallelen Bearbeitung mit anderen Funktionen betrieben werden.
Der Verbindungsserver 114 kann im gleichen Computer betrieben werden, in dem der Laborserver 112 vorliegt. Für zusätzliche Verlässlichkeit kann der Verbindungsserver 114 in der bevorzugten Ausführungsform in einem separaten Computer ausgeführt werden. Der Verbindungsserver 114 kann unter Verwendung zielorientierter, netzwerkfähiger und multithreading-fähiger Softwareentwicklungsumgebungen, wie z.B. JAVA oder C++, implementiert sein. Zwei der vom Verbindungsserver 114 durchgeführten Hauptfunktionen umfassen: Überwachen und Aufrechterhalten verlässlicher Netzwerkverbindungen mit sämtlichen aktiven Clients und Laborservern; sowie Leiten von DNP-Paketen an geeignete Ziele.
Der Verbindungsserver 114 verwaltet Netzwerkverbindungen mit sämtlichen Prozessen, nämlich: mit dem Laborserver 112, dem Datenbankserver 120 und den Clients 118. Eine Verbindungssteuerung, die gegebenenfalls eine Klasse oder ein Objekt in objektorientierter Programmierungsterminologie ist, kann Ablesungen von jeder der Verbindungen vornehmen und darauf aufzeichnen. Jede der Verbindungssteuerungen sollte in einem getrennten Thread zur parallelen Verarbeitung betrieben werden. Nachdem der Verbindungsserver 114 eine Verbindung annimmt oder erstellt, kann dieser die Verbindungsinformation (nämlich die Socket-Information, welche Fernadresse und Fernportnummer enthält) anschließend zur weiteren Verarbeitung an die Verbindungssteuerung weiterleiten. Der Verbindungsserver 114 verwaltet ein Feld oder eine Tabelle an Verbindungssteuerungen, nämlich die Verbindungstabelle, um netzwerkbezogene Prozesse auszuführen und zu überwachen. Ein Verbindungsmonitor stellt einen anderen wichtigen Prozess dar, der im Verbindungsserver 114 enthalten ist und in regelmäßigen Abständen betrieben wird. Der Verbindungsmonitor kann als Unterklasse des Verbindungsservers 114 implementiert sein und in einem getrennten Thread ausgeführt werden. Eine Funktion des Verbindungsmonitors besteht in der Überwachung und Steuerung der Netzwerkkommunikation der Prozesse (nämlich der Clients 118 und dem Laborserver 112), die mit dem Verbindungsserver verbunden sind.
7 veranschaulicht den Grundbetrieb des Verbindungsmonitors. Bei Schritt 550 beginnend, sucht der Verbindungsmonitor nach Clients in der Verbindungstabelle. Auf Entscheidungsschritt 552 weitergehend, schreitet die Steuerung auf Schritt 554 fort, wenn ein Client in der Verbindungstabelle gefunden wird, wonach der Verbindungsmonitor die Validität der aktuellen Sitzung überprüft. Dieser Betrieb erfolgt normalerweise durch Befragen des Datenbankservers 120, um zu überprüfen, ob die aktuellen Clients Zugang zum physikalischen Prozess 110 haben. Wenn ein Client nicht gefunden wird, geht die Steuerung vom Entscheidungsschritt 552 auf 556 über, bei dem der Verbindungsmonitor sämtliche Verbindungssteuerungen anweist, ihre Verbindungen zu schließen. Auf Schritt 554 zurückgehend, geht die Steuerung auf Entscheidungsschritt 558 über. Wenn die Sitzung zulässig ist, geht die Steuerung weiter auf Schritt 560; andernfalls geht die Steuerung auf Schritt 556 zurück. Bei Schritt 560 sucht der Verbindungsmonitor nach einem Laborserver 112 in der Verbindungstabelle. Die Steuerung geht weiter auf Schritt 562, bei dem das Programm beendet wird, wenn ein Laborserver gefunden wird. Andernfalls geht die Steuerung weiter auf Schritt 564, bei dem der Verbindungsmonitor eine Verbindung mit einem Laborserver 112 herstellt. Wie in 7 gezeigt, wird die Bedienung zur Überprüfung, ob ein Laborserver 112 verbunden ist, in einer Schleife durchgeführt, da es gegebenenfalls mehr als einen Laborserver 112 gibt, der für Sicherungszwecke kontaktiert ist. Wenn es zu einem Fehler im System oder einer Vorrichtung im physikalischen Prozess 110 kommt, würde der Laborserver 112, welcher physikalisch mit dem physikalischen Prozess 110 verbunden ist, jegliche Verbindungsanforderungen seitens des Verbindungsservers ablehnen. Folglich versucht der Verbindungsmonitor, eine Verbindung mit einem anderen Laborserver 112 zu erstellen. Die gesamte Bedienung in 7 sollte in regelmäßigen Abständen durchgeführt werden, um den Kommunikationsprozess kontinuierlich zu übeerwachen.
Der Verbindungsserver dient als Verteiler von Daten, die DNP-Pakete annimmt, verifiziert und an geeignete Ziele leitet. Der Verbindungsserver unterstützt Duplex-Punkt-zu-Punkt- und Punkt-zu-Mehrpunkt-Datenübertragungen, bezogen auf das Ziel-ID-Feld des DNP-Pakets. Daraus geht hervor, dass sowohl Clients 118 als auch Laborserver-112-Prozesse Ereignisse, die von beliebigen Prozessen erzielt werden, synchron empfangen können. 8 zeigt mehrere Routing-Modi, die vom Verbindungsserver durchgeführt werden können. 8 ist ein Beispiel für drei Clients und einen Laborserver, der mit dem Verbindungsserver verbunden ist. Die Maximalanzahl an Clients, welche betreut werden können, hängt von der verfügbaren Netzwerkbandbreite ab.
Wie oben besprochen, ist die Verbindungssteuerung Teil des Verbindungsservers und kann Ablesungen von jeder der Verbindungen und Aufzeichnungen darauf ausführen. Der Verbindungsserver 114 befolgt jede beliebige Verbindungsanforderung und leitet die Netzwerkinformation an die Verbindungssteuerung weiter, sobald eine zulässige Verbindung hergestellt worden ist. 9 zeigt das Flussdiagramm der Verbindungssteuerung. Bei Schritt 600 beginnend, empfängt die Verbindungssteuerung Netzwerkinformationen aus einer annehmbaren Verbindung vom Verbindungsserver. Die Steuerung geht weiter auf Schritt 602, bei dem die Verbindungssteuerung überprüft, ob die Verbindung zulässig ist. Wenn die Verbindung nicht zulässig ist (Entscheidungsschritt 604), schreitet die Steuerung auf Schritt 606 weiter, bei dem die Verbindungssteuerung die Verbindung schließt und die Steuerung beendet wird. Wenn die Verbindung jedoch zulässig ist, geht die Steuerung auf Schritt 608 weiter, bei dem die Verbindungssteuerung wartet und eine bestimmte Zeitsperrendauer lang ankommende DNP-Pakete abhört. Von Schritt 608 schreitet die Steuerung auf Entscheidungsschritt 610 weiter. Beim Entscheidungsschritt 610 geht die Steuerung auf Schritt 612 weiter, wenn ein DNP-Paket vor der Zeitsperre erhalten wird, bei dem der Verwaltungsdatenabschnitt des DNP-Pakets gelesen wird. Wenn ein DNP-Paket jedoch nicht vor der Zeitsperre erhalten wird, geht die Steuerung auf Schritt 602 zurück. Von Schritt 612 aus, geht die Steuerung weiter auf Schritt 614, bei dem die Verbindungssteuerung erneut versucht, die Verbindung zu validieren. Wenn die Verbindung nicht zulässig ist (Entscheidungsschritt 616), geht die Steuerung auf Schritt 606 zurück. Wenn die Verbindung jedoch zulässig ist, schreitet die Steuerung auf Schritt 618 weiter, bei dem der Rest des DNP-Pakets gemäß seiner Paketlänge gelesen wird. Die Steuerung geht auf Schritt 620 weiter, bei dem die Verbindungssteuerungen in der Verbindungstabelle, bezogen auf die Ziel-ID im DNP-Verwaltungsdatenabschnitt, gefunden werden. Die Steuerung geht anschließend weiter auf Schritt 622, bei dem sämtliche DNP-Pakete an sämtliche Ziele über die Verbindungssteuerungen gesendet werden, die in der Verbindungstabelle zu finden sind. Von Schritt 622 aus geht die Steuerung auf Schritt 602 zurück. Die oben beschriebenen Betätigungen werden wiederholt bis die Verbindung nicht mehr zulässig ist.
Client-Prozesse stellen eine grafische Benutzeroberfläche für die Endverbraucher des physikalischen Prozesses 110 bereit. Die Clients können in jeglicher zielorientierter, netzwerkfähiger und multithreading-fähiger Softwareentwicklungsumgebung, wie z.B. JAVA oder C++, implementiert sein. Der Client sollte grafische Komponenten enthalten, die verwendet werden können, um Benutzereingaben und/oder Anzeigeinformationen zu erhalten. Einige der Komponenten können Skalen, Grafiken, Schalter, LED-Anzeigen, Knöpfe, etc. umfassen.
Der Client-Prozess 118 kann von jedem beliebigem Computer ausgeführt werden, der mit einem TCP/IP-Netzwerk, wie z.B. das Internet, verbunden ist. Wenn der Client-Prozess läuft, versucht dieser zuerst Netzwerkverbindungen mit dem Verbindungsserver 114 herzustellen. Benutzeranforderungen/-befehle, die von den UI-Komponenten erhalten werden, werden in DNP-Pakete kodiert, um an den Verbindungsserver 114 geschickt zu werden. Der Client 118 kann auch DNP-Pakete von anderen entfernten Clients und Laborservern 112 verarbeiten, die über den Verbindungsserver 114 erhalten werden. Diese Betätigung kann auch in einem getrennten Thread zur parallelen Verarbeitung ausgeführt werden.
10 ist ein Flussdiagramm einer Client-DNP-Paketverarbeitung. Der Client-Prozess 118 führt die Anweisungen in einem DNP-Paket normalerweise durch, indem er Funktionen oder Verfahren seiner UI-Komponenten aufruft. Die Anweisungen können das Aktualisieren der Grafikanzeige, das Drehen einer Wählscheibe, das Kodieren und Anzeigen von Videodaten, etc. beinhalten. Durch Empfangen von Echtzeit-Ereignissen von physikalischen Prozessen 110 und anderen Client-Prozessen, kann der Benutzer eine interaktive und gemeinschaftliche Umgebung bei der Steuerung von entfernten physikalischen Prozessen erleben. Bei Schritt 624 beginnend, wartet der Client auf das DNP-Paket aus dem Verbindungsserver 114. Die Steuerung schreitet sodann auf Schritt 626 voran, bei dem der Verwaltungsdatenabschnitt des DNP-Pakets gelesen wird. Die Steuerung geht sodann auf Schritt 628 über, bei dem eine Anweisung im Anweisungsabschnitt des DNP-Pakets gelesen wird. Die Steuerung geht anschließend weiter auf Schritt 629, bei dem die Anforderung/Anweisung ausgeführt wird, indem die Funktionen der Benutzeroberflächenkomponenten aufgerufen werden. Von Schritt 629 aus kann die Steuerung auf Schritt 628 in einer Schleife zurückgehen, die gemäß der Anzahl an Anweisungen wiederholt wird.
Der Datenbankserver 120 verwaltet die Datenbank, welche Informationen enthält, die zur Betätigung anderer Prozesse essentiell sind. Die Fernbetätigung des Datenbankservers 120 kann erleichtert werden, indem Schnittstellenprogrammierungsstandards für Datenbankanwendungen, wie z.B. ODDC oder JDDC, verwendet werden. Der Datenbankserver 120 verwaltet die folgende Liste an Informationen: Benutzerinformation, physikalische Prozessdaten des Benutzers, Planungsinformationen und Ereignisdaten.
Der Datenbankserver 120 verwaltet Benutzerprofile. Ein Benutzerprofil enthält Benutzerzugangsinformationen, wie z.B. Login-Name und Passwort, die es dem Verbindungsserver 114 ermöglichen, Verbindungsanforderungen von den Clients 118 zu verifizieren. Ferner umfasst das Benutzerprofil auch die Clients-Verlaufsinformation durch Überprüfen des Status erfüllter Maßnahmen/Anforderungen. Daten aus den physikalischen Prozessen 118 (nämlich Sensorablesungen, Gerätezustand, etc.) können auch im Namen einer Client-Anforderung aufgezeichnet werden. Diese Daten können mit einem Zeitstempel versehen und dem Benutzer über eine interaktive "Labor-Notebook"-Benutzeroberfläche zugänglich gemacht werden. Mit einem Common Gateway Interface (CGI) oder einem JAVA-Servletprogramm, das mit dem Datenbankserver 120 interagieren kann, können Clients zuvor aufgezeichnete physikalische Prozessdaten suchen und abrufen. Die Suche kann in chronologischer Reihenfolge, mittels Schlüsselworten oder anderen Merkmalen der aufgezeichneten Daten erfolgen. Das Planen von Information gewährleistet, dass nur die geeigneten Clients Zugang zu den physikalischen Prozessen 110 in einer bestimmten Zeitdauer erhalten. Jeder vom Laborserver erhaltene Anreiz kann auch automatisch aufgezeichnet werden. Diese Daten können verwendet werden, um das Verhalten von Clients zu analysieren und Muster bei der Steuerung des physikalischen Prozesses 110 zu verwenden. Das interaktive Labor-Notebook kann auch Laborparameter, Aufgabenlisten und persönliche Notizen enthalten.
Das interaktive Labor-Notebook ist Teil einer Benutzeroberfläche, die mit einem Interface Builder oder einer ähnlichen Softwareanwendung aufgebaut werden kann, und Benutzer können während eines Versuchs darauf zugreifen. Das interaktive Labor-Notebook kann implementiert werden, um eine Datenbank, die auf einer Festplatte oder einem anderen nichtflüchtigen Speicher von Computer 60 gespeichert ist, sowie eine Benutzeroberfläche für den Zugriff auf die Datenbank zu umfassen. Wenn die vorliegende Erfindung für Fernlernen verwendet wird, stellt das interaktive Labor-Notebook eine Zentralquelle für Informationen bereit und stellt ein essentielles Instrument für Lehrende dar, um die Entwicklung und die Leistung von Schülern und Studenten, die das Online-Labor benutzen, zu bewerten.
Die Benutzeroberfläche kann eher animierte Schalter, Wählscheiben, Knöpfe und LED-Anzeigen enthalten als herkömmliche Browser-Formen. Das Erstellen von Online-Grafiken der Echtzeitdaten zusammen mit anderen kundenspezifisch ausgeführ ten Benutzeroberflächenkomponenten vermittelt Benutzern einen übungssituationsartigen Eindruck und eine entsprechende Atmosphäre. Die Benutzeroberfläche kann Frontplatten tatsächlicher Geräte hinsichtlich Funktionalität, Layout und Erscheinungsbild gleichen. Der Echtzeitvideostrom kann auch in der Benutzeroberfläche enthalten sein.
Echtzeitvideoüberwachung
Das Beobachten physikalischer Prozesse in Echtzeit über das Internet ist ein Hauptmerkmal der vorliegenden Erfindung. Bezugnehmend auf 1B wird die Videokamera 70 verwendet, um Echtzeitbilder aus einem System zu erfassen, mit dem der Benutzer interagiert und dessen Handlungen das beobachtete Video beeinflussen. Video-Capture-(oder Framegrabber-)Hardware 72 wird auf einem Computer verwendet, um Bilder zu erfassen, die an einen Benutzer wünschenswert mit minimaler Latenzzeit geschickt werden. Ein Videoserver-Computer 74 komprimiert neue Bilddaten und bildet Pakete, die dem Benutzer (Client) durch das Computernetzwerk 50 übermittelt werden. Der Client, der einen Standardbrowser verwendet, ist in der Lage, das Echtzeitvideo anzuschauen und mit dem System zu interagieren. Zur Übertragung von Video über das Internet in Echtzeit wird eine räumliche und zeitliche Komprimierung durchgeführt. Bei der räumlichen Komprimierung wird das vom Framegrabber 72 erfasste Bild als Grauskala oder als Farbbild hinsichtlich Farbton, Sättigung und Wert (HSV) dargestellt. In beiden Fällen sind die Werte als ganze Zahlen dargestellt. Die Bilddaten werden in Quadratblöcke (beispielsweise 8×8 Pixel oder 16×16 Pixel) unterteilt. Eine zweidimensionale diskrete Kosinustransformation (ein mathematisches Standardverfahren, das häufig als DCT abgekürzt wird) wird auf jedem der Blocks durchgeführt.
Zur Durchführung von zeitlichen Komprimierungen subtrahiert der Server 74 die idealen DCT-Daten von den DCT-Daten, über die der Client gegenwärtig verfügt. Diese Differenz hinsichtlich DCT-Daten ist die Information, die der Client erhalten muss, damit ermöglich wird, dass sein Video auf das gewünschte Bild aktualisiert wird. Dies geht auf Kosten der Komprimierungseffizienz (nämlich jener, die unter Verwendung des MPEG4-Standards erhalten wird), womit die Latenzzeit minimiert wird. Eine Annäherung an diese Differenz wird ermittelt, die den Erfordernissen der spezifizierten Festpaketgröße (in Bit spezifiziert) entspricht. Indem Komprimierung auf eine spezifizierte Paketgröße bezogen wird, entspricht das komprimierte Video den Übertragungslimitierungen des Clients 110. Die Datenrate (PAKET_GRÖSSE*PAKETE_PRO_SEKUNDEN), die für einen bestimmten Client verwendet wird, wird bei Verschicken von Videos dynamisch bestimmt und aktualisiert. Dies ermöglicht, dass die Qualität des an einen Client geschickten Videos je nach den Fähigkeiten der jeweiligen Internetverbindung des Clients variiert. Dies lässt auch zu, dass die Datenrate als Antwort auf Veränderungen in der zulässigen Datenrate des Clients variiert wird. Indem der Client den Server periodisch von den Zeitintervallen in Kenntnis setzt, in denen übertragene Pakete erhalten wurden, können Latenzzeit und zulässige Datenrate des Clients berechnet werden.
11 zeigt das zweidimensionale Set von DCT-Komponenten. Komponente 0 befindet sich in der oberen linken Ecke und der Pfeil zeigt die Reihenfolge, in der jede der Komponenten aufgezählt ist. DCT-Komponenten werden in Komponentengruppen (nämlich 8 Gruppen von 8 Komponenten) übertragen. Nicht alle Gruppen von DCT-Komponenten werden in einem Einzelpaket übertragen. Gruppen von "unterschiedlichen DCT-Daten" werden zum Senden ausgewählt, bezogen auf die Größe der Komponenten in der Gruppe. In acht SV-Bildern ist das Auge gegenüber Wertunterschieden sensibler als gegenüber Unterschieden im Farbton oder in der Sättigung. Folglich wird ein relatives Gewicht verwendet, um die Größen der Gruppen oder eines unterschiedlichen Typs zu vergleichen. Daten werden mit Abrundungen übertragen, um weniger Bit zu verwenden, damit eine Annäherung der Daten übertragen wird. Das Videokomprimierungssystem wurde optimiert, um die Antwortzeit (Latenzzeit) zu minimieren. Diese Priorität ist einzigartig für ein System, das vom Benutzer abhängt, der sofort Videorückmeldungen als Antwort auf seine Handlungen erhält.
12 zeigt den vom Server 74 durchgeführten Kodierungsprozess. Bei Schritt 630 beginnend werden die aktuellen DCT-Daten für den Client auf Null eingerichtet. Die Steuerung geht weiter auf Schritt 632, bei dem die Einrichtungsinformation an den Beginn des Pakets platziert wird, wenn es sich dabei um das erste zu übertragende Paket handelt. Diese Einrichtungsinformation umfasst: Anzeigenbreite, Anzeigenhöhe und Anzeigentyp (Grauskala oder HSV). Die Steuerung geht weiter auf Schritt 634, bei dem mittels Videokamera 70 und Framegrabber 72 ein Bild erfasst wird. Bei Schritt 636 werden Bilddaten in quadratische Blocks (8×8 Pixel oder 16×16 Pixel) unterteilt. Bei Schritt 638 wird eine zweidimensionale diskrete Kosinustransformation auf jedem der Blocks durchgeführt. Dies ergibt die idealen DCT-Daten, was einem Bild mit minimalem Fehler entspricht.
Bei Schritt 640 wird der Unterschied zwischen idealen DCT-Daten und jenen DCT-Daten, welche vom Client zu jenem Zeitpunkt benutzt werden, ermittelt. Dies führt zu einem "Unterschied der DCT-Daten". Bei Schritt 642 werden Gruppen von "unterschiedlichen DCT-Daten" zum Senden ausgewählt, bezogen auf die Größe der Komponenten in der Gruppe. In HSV-Bildern ist das Auge gegenüber Wertunterschieden sensibler als gegenüber Unterschieden im Farbton oder in der Sättigung. Folglich wird ein relatives Gewicht verwendet, um die Größen der Gruppen von unterschiedlichem Typ zu vergleichen. Bei Schritt 644 wird eine Annäherung an die Daten in diesen Gruppen in einem Paket gespeichert, das anschließend über das Netzwerk durch eine Socketverbindung mit dem Client übertragen wird. Die Steuerung geht weiter auf Schritt 648, bei dem der "angenäherte Unterschied hinsichtlich DCT-Daten", die vom Client dekodiert werden, anschließend vom Server 74 berechnet. Bei Schritt 650 wird dieser Unterschied anschließend zu den DCT-Daten des Clients addiert, über die der Server 74 Aufzeichnungen führt. Durch Erfassen der aktuellen Client-Daten wird der durch die Annäherung verursachte Fehler nicht weiterverbreitet, da Mehrfachübertragungen gesendet werden. Die Steuerung kann anschließend auf Schritt 632 zurückgehen, um ein weiteres an den Client zu sendendes Paket zu erstellen.
13 zeigt die Struktur des vom Client durchgeführten Dekodierungsprozesses. Bei Schritt 652 beginnend werden die aktuellen DCT-Daten für den Client auf Null eingerichtet. Bei Schritt 654 wird eine Socketverbindung verwendet, um ein Paket vom Server 74 zu erhalten. Bei Schritt 656 wird Einrichtungsinformation verarbeitet, wenn es sich dabei um das erste erhaltene Paket handelt. Diese Einrichtungsinformation umfasst: Anzeigenbreite, Anzeigenhöhe und Anzeigentyp (Grauskala oder HSV). Bei Schritt 658 wird das Paket dekodiert, um den angenäherten Unterschied hinsichtlich DCT-Daten zu erstellen. Bei Schritt 660 wird der aktualisierte Wert für die gegenwärtigen DCT-Daten bestimmt, indem dieser Unterschied wieder zu den gegenwärtigen DCT-Daten addiert wird. Die Steuerung geht weiter auf Schritt 662, bei dem die diskrete Kosinustransformation verwendet wird, um DCT-Daten in Bilddaten umzuwandeln. Diese Transformation wird nur auf Blocks durchgeführt, die mittels angenähertem Unterschied hinsichtlich DCT-Daten modifiziert worden sind. Dadurch können die Bilddaten ohne Pufferung aktualisiert werden, und folglich wird die Verzögerung bei der Aktualisierung des Bildes minimiert. Die Steuerung geht weiter auf Schritt 664, bei welchem dem Benutzer durch einen Standardbrowser das Bilddatum angezeigt wird. Die Steuerung kann dann auf Schritt 654 zurückgehen, um ein zusätzlich aktualisiertes Bild zu verarbeiten, das vom Server 74 gesendet wurde.
Die oben beschriebenen Anweisungen sowie die Benutzeroberfläche und das interaktive Labor-Notebook können in Software implementiert, im Computer 60 gespeichert und gemäß der bevorzugten Ausführungsform der vorliegenden Erfindung ausgeführt werden.
Obwohl in obiger Beschreibung die Betätigung eines Laser- und optischen Geräts erläutert wird, kann unter Verwendung vorliegender Erfindung eine breite Reihe von physikalischen Prozessen durchgeführt werden kann, und andere Datenformen, wie z.B. Zeit, Temperatur, Spannung, Strom, Magnetfeld, elektromagnetische Strahlung und dergleichen können, aufgezeichnet werden. Zusätzliche Anwendungen der vorliegenden Erfindung können auf Unterhaltung erweitert werden, wie z.B. Fernbedienungen für Spielsachen in interaktiver Einstellung, bei der Mehrfachbenutzer über das Computernetzwerk 50 Zugriff auf Computer 60 haben und Spiele spielen, die Mehrfachbenutzer einschließen. Das von der vorliegenden Erfindung gelehrte Echtzeit-Video ist ein integrierter Teil einer solchen Anwendung.
In anderen Anwendungen der vorliegenden Erfindung können Computer 60 und Kamera 70 als Verkaufs- oder Entwicklungsinstrument verwendet werden, um Geräte oder Prozesse potentiellen Clients, Kunden oder Entwicklern vorzustellen, indem eine Demonstration des Geräts oder der Prozesse in Echtzeit bereitgestellt und die Ausgaben für Ressourcen wegfallen, die benötigt werden, um zu einem Ort zu gelangen, an dem sich die Geräte oder Prozesse befinden.

Claims

System für den Fernzugriff und die Fernbetätigung einer elektronischen Vorrichtung, die einen physikalischen Prozess (110) detektiert, misst, quantifiziert und/oder steuert, wobei das System Folgendes umfasst: die elektronische Vorrichtung und zumindest einen Laborserver (112), der mit der elektronischen Vorrichtung operativ gekoppelt ist und konfiguriert ist, um den physikalischen Prozess über die elektronische Vorrichtung zu überwachen und zu steuern; eine Vielzahl an Client-Rechnervorrichtungen (118), auf denen eine Software läuft, die Steuerbefehle für die elektronische Vorrichtung bereitstellt und von der elektronischen Vorrichtung den physikalischen Prozess betreffende Daten empfängt; und einen Verbindungsserver (114), der zur Aufrechterhaltung von Verbindungen mit den Client-Rechnervorrichtungen und dem Laborserver fähig ist, wobei der Verbindungsserver konfiguriert ist, um die Steuerbefehle von den Client-Rechnervorrichtungen an den Laborserver zu leiten und um Daten als Punkt-zu-Mehrpunkt-Übertragungen vom Laborserver an die Client-Rechnervorrichtungen zu leiten, dadurch gekennzeichnet, dass der Verbindungsserver weiters konfiguriert ist, um die Steuerbefehle als Punkt-zu-Mehrpunkt-Übertragungen zwischen den Client-Rechnervorrichtungen zu leiten, wodurch die gemeinschaftliche Steuerung der elektronischen Vorrichtung ermöglicht wird.
System nach Anspruch 1, weiters umfassend eine Vielzahl an Laborservern, worin der Verbindungsserver zur Aufrechterhaltung von Verbindungen mit jedem Laborserver fähig ist und der Verbindungsserver konfiguriert ist, um Daten von den Laborservern an die Client-Rechnervorrichtungen zu leiten und um die Steuerbefehle als Punkt-zu-Mehrpunkt-Übertragungen von den Client-Rechnervorrichtungen an die Laborserver zu leiten.
System nach Anspruch 2, worin der Verbindungsserver konfiguriert ist, um zumindest entweder Daten oder Steuerbefehle als Punkt-zu-Mehrpunkt-Übertragungen zwischen den Laborservern zu leiten.
Verfahren für den Fernzugriff und die Fernbetätigung einer elektronischen Vorrichtung, die einen physikalischen Prozess (110) detektiert, misst, quantifiziert und/oder steuert, wobei das Verfahren Folgendes umfasst: (a) die Herstellung von Netzwerkverbindungen zwischen einer Vielzahl an Client-Rechnervorrichtungen (118) und einem Verbindungsserver (114); (b) die Herstellung einer Netzwerkverbindung zwischen einem Laborserver (112) und dem Verbindungsserver (114), wobei der Laborserver mit der elektronischen Vorrichtung operativ gekoppelt ist und konfiguriert ist, um den physikalischen Prozess über die elektronische Vorrichtung zu überwachen und zu steuern und um den physikalischen Prozess betreffende Daten von der elektronischen Vorrichtung zu empfangen; und (c) das Leiten von Steuerbefehlen für den Laborserver von den Client-Rechnervorrichtungen über den Verbindungsserver an den Laborserver, und das Leiten von den physikalischen Prozess betreffende Daten als Punkt-zu-Mehrpunkt-Übertragungen vom Laborserver über den Verbindungsserver an die Client-Rechnervorrichtungen; dadurch gekennzeichnet, dass die Steuerbefehle weiters über den Verbindungsserver als Punkt-zu-Mehrpunkt-Übertragungen zwischen den Client-Rechnervorrichtungen geleitet werden, wodurch die gemeinschaftliche Steuerung der elektronischen Vorrichtung ermöglicht wird.
Verfahren nach Anspruch 4, worin die Übertragung der Daten und der Steuerbefehle unter Verwendung eines gemeinsamen Protokolls durchgeführt wird, das eine Vielzahl an Paketen umfasst, wobei jedes Paket einen Verwaltungsabschnitt (205), der Quellen- und Zielidentifikationsinformationen enthält, und einen Befehlsabschnitt (255), der die Steuerbefehle oder die Daten enthält, umfasst.
Verfahren nach Anspruch 4 oder 5, weiters umfassend das Leiten der Daten von zumindest einem aus Laborserver und Client-Rechnervorrichtungen zu einem Datenbankserver und das Speichern der Daten in der Datenbank.
Verfahren nach einem der Ansprüche 4 bis 6, worin Netzwerkverbindungen zwischen einer Vielzahl an Laborservern und dem Verbindungsserver geschaffen werden und zumindest entweder die Daten oder die Steuerbefehle als Punkt-zu-Mehrpunkt-Übertragungen zwischen den Laborservern geleitet werden.