DE102005029440A1 - System und Verfahren zum Synchronisieren von Operationen einer Mehrzahl von Vorrichtungen über Meldungen über ein Kommunikationsnetzwerk - Google Patents

System und Verfahren zum Synchronisieren von Operationen einer Mehrzahl von Vorrichtungen über Meldungen über ein Kommunikationsnetzwerk Download PDF

Info

Publication number
DE102005029440A1
DE102005029440A1 DE102005029440A DE102005029440A DE102005029440A1 DE 102005029440 A1 DE102005029440 A1 DE 102005029440A1 DE 102005029440 A DE102005029440 A DE 102005029440A DE 102005029440 A DE102005029440 A DE 102005029440A DE 102005029440 A1 DE102005029440 A1 DE 102005029440A1
Authority
DE
Germany
Prior art keywords
event
message
action
devices
timestamp
Prior art date
Legal status (The legal status is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the status listed.)
Ceased
Application number
DE102005029440A
Other languages
English (en)
Inventor
Daniel L. Santa Rosa Pleasant
Gopalakrishnan Santa Rosa Kailasam
Current Assignee (The listed assignees may be inaccurate. Google has not performed a legal analysis and makes no representation or warranty as to the accuracy of the list.)
Agilent Technologies Inc
Original Assignee
Agilent Technologies Inc
Priority date (The priority date is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the date listed.)
Filing date
Publication date
Application filed by Agilent Technologies Inc filed Critical Agilent Technologies Inc
Publication of DE102005029440A1 publication Critical patent/DE102005029440A1/de
Ceased legal-status Critical Current

Links

Classifications

    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L41/00—Arrangements for maintenance, administration or management of data switching networks, e.g. of packet switching networks
    • H04L41/06—Management of faults, events, alarms or notifications
    • G—PHYSICS
    • G04—HOROLOGY
    • G04G—ELECTRONIC TIME-PIECES
    • G04G15/00—Time-pieces comprising means to be operated at preselected times or after preselected time intervals
    • G—PHYSICS
    • G04—HOROLOGY
    • G04G—ELECTRONIC TIME-PIECES
    • G04G7/00—Synchronisation
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04J—MULTIPLEX COMMUNICATION
    • H04J3/00—Time-division multiplex systems
    • H04J3/02—Details
    • H04J3/06—Synchronising arrangements
    • H04J3/0635—Clock or time synchronisation in a network
    • H04J3/0638—Clock or time synchronisation among nodes; Internode synchronisation
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04J—MULTIPLEX COMMUNICATION
    • H04J3/00—Time-division multiplex systems
    • H04J3/02—Details
    • H04J3/06—Synchronising arrangements
    • H04J3/0635—Clock or time synchronisation in a network
    • H04J3/0638—Clock or time synchronisation among nodes; Internode synchronisation
    • H04J3/0658—Clock or time synchronisation among packet nodes
    • H04J3/0661—Clock or time synchronisation among packet nodes using timestamps
    • H04J3/0664—Clock or time synchronisation among packet nodes using timestamps unidirectional timestamps
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04J—MULTIPLEX COMMUNICATION
    • H04J3/00—Time-division multiplex systems
    • H04J3/02—Details
    • H04J3/06—Synchronising arrangements
    • H04J3/0635—Clock or time synchronisation in a network
    • H04J3/0638—Clock or time synchronisation among nodes; Internode synchronisation
    • H04J3/0658—Clock or time synchronisation among packet nodes
    • H04J3/0661—Clock or time synchronisation among packet nodes using timestamps
    • H04J3/0667—Bidirectional timestamps, e.g. NTP or PTP for compensation of clock drift and for compensation of propagation delays
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L41/00—Arrangements for maintenance, administration or management of data switching networks, e.g. of packet switching networks
    • H04L41/22—Arrangements for maintenance, administration or management of data switching networks, e.g. of packet switching networks comprising specially adapted graphical user interfaces [GUI]

Landscapes

  • Engineering & Computer Science (AREA)
  • Computer Networks & Wireless Communication (AREA)
  • Signal Processing (AREA)
  • Physics & Mathematics (AREA)
  • General Physics & Mathematics (AREA)
  • Synchronisation In Digital Transmission Systems (AREA)
  • Data Exchanges In Wide-Area Networks (AREA)

Abstract

Ein System und ein Verfahren synchronisieren Operationen einer Mehrzahl von Vorrichtungen über Meldungen über ein Kommunikationsnetzwerk. Eine Mehrzahl von Vorrichtungen ist kommunikativ über ein Kommunikationsnetzwerk gekoppelt, und die Vorrichtungen haben ihre lokalen Takte zu einem hohen Präzisionsgrad synchronisiert durch eine Technik, wie z. B. IEEE 1588, zum Synchronisieren ihrer lokalen Takte. Ereignismeldungen können gesendet werden, die eine Identifikation eines Ereignisses sowie einen Zeitstempel umfassen, der auf dem lokalen Takt des Senders basiert. Der Empfänger einer Ereignismeldung bestimmt, ob er konfiguriert ist, um auf das identifizierte Ereignis hin zu handeln, und wenn ja, unternimmt derselbe seine Aktion, basierend auf dem Zeitstempel, der in der Ereignismeldung umfasst ist. Bei bestimmten Ausführungsbeispielen müssen die Ereignisse auslösen, dass eine Aktion und/oder die spezifischen Antwortaktionen, die für ein gegebenes Ereignis durchgeführt werden sollen, dynamisch für jede Vorrichtung programmierbar sind.

Description

  • Bezugnahme auf verwandte Anmeldungen
  • Diese Anmeldung bezieht sich auf gleichzeitig eingereichte und gemeinsam zugewiesene deutsche Patentanmeldungen Anwaltsaktenzeichen AG050618PDE mit dem Titel „SYSTEM UND VERFAHREN ZUM KOORDINIEREN DER AKTIONEN EINER MEHRZAHL VON VORRICHTUNGEN ÜBER EIN PLANEN DER AKTIONEN BASIEREND AUF SYNCHRONISIERTEN LOKALEN TAKTEN", Anwaltsaktenzeichen Nr. AG050620PDE mit dem Titel „SYSTEM UND VERFAHREN ZUR STABILEN KOMMUNIKATION ÜBER EIN UNZUVERLÄSSIGES PROTOKOLL" und Anwaltsaktenzeichen Nr. AG050619PDE mit dem Titel „ZUSATZMODUL ZUM SYNCHRONISIEREN VON OPERATIONEN EINER MEHRZAHL VON VORRICHTUNGEN", deren Offenbarungen hierin durch Bezugnahme aufgenommen sind.
  • Beschreibung
  • Die Synchronisation der Operation verschiedener Komponenten eines Systems ist häufig erwünscht. Zum Beispiel bei Messsystemen, die aus mehreren traditionellen Alles-in-Einem-Gehäuse-Instrumenten bestehen, erfordern komplexe Messungen häufig, dass verschiedene Instrumente zusammen gesteuert werden, um ihre entsprechenden Operationen ordnungsgemäß zu synchronisieren. Als Beispiele sollte es Spektrum-Analysatoren nicht erlaubt sein, Messungen durchzuführen, bis Signalquellen eingeschwungen sind; Leistungsmesser-Messungen sollten nicht genommen werden, bis eine ausreichende Anzahl von Proben gemittelt wurde, um eine Genauigkeit sicherzustellen; und Frequenzwobbelungsquellen sollte es nicht erlaubt sein, auf eine neue Frequenz zu schalten, bis Messungen bei der aktuellen Frequenz abgeschlossen sind. Somit wird es wünschenswert, die relativen Operationen der verschiedenen Instrumente zu synchronisieren.
  • Häufig werden Hardware-Auslöserleitungen verwendet, um die verschiedenen Instrumente in einem System zu synchronisieren. Hardware-Auslöserleitungen sind besonders wirksam bei Messsystemen, wo eine präzise Synchronisation erforderlich ist, oder wo eine Messgeschwindigkeit wichtig ist. Wenn Hardware-Auslöserleitungen implementiert werden, weisen die Instrumente einen Auslöser-Ausgang und einen Auslöser-Eingang mit einer zweckgebundenen Hardwareleitung auf (z. B. Draht), die den Auslöserausgang eines Instruments mit dem Auslösereingang eines anderen Instruments verbindet.
  • Zum Beispiel umfasst ein Spektrumanalysator üblicherweise einen Empfänger und einen Digitalisierer in dem selben Gehäuse, wobei das Ausgangssignal aus dem Empfänger gemessen werden sollte, nachdem es eine gewisse Zeitperiode zum Einschwingen hatte. Beim Implementieren von Hardware-Auslöserleitungen zwischen dem Empfänger und dem Digitalisierer würde der Empfänger ein Auslöser-Ausgangstor aufweisen, das über eine Hardwareleitung (z. B. Draht) mit dem Auslösereingangstor des Digitalisierers gekoppelt ist. Die Spannung auf dieser Hardwareleitung geht zu der Zeit hoch, zu der das Ausgangssignal von dem Empfänger eingeschwungen ist, und der Auslösereingang der Digitalisierereinheit erfasst diesen Spannungsübergang hin zu hoch und löst somit den Beginn der Messung aus. Somit stellt die Hardware-Auslöserleitung sicher, dass die relativen Operationen der Instrumente auf eine gewünschte Weise synchronisiert werden.
  • Die Hardware-Auslöserleitungs-Technik erfordert einen physischen Draht, der zwischen diesen zwei Instrumenten verläuft, und die Funktion dieses Drahts ist fest und zweckgebunden zur Verwendung als ein Auslöser. Ferner erhöht die Einlagerung solcher Hardware-Auslöserleitungen die Menge an Verdrahtung und führt somit häufig zu Verdrahtungs-Komplexitäten und/oder -Komplikationen, wie z. B. Problemen im Hinblick auf die Wegleitung der Drähte und eine erhöhte Schwierigkeit beim Beheben von Problemen. Ferner, wenn sich die Länge der Hardware-Auslöserleitung erhöht (z. B. weil die gekoppelten Instrumente weiter voneinander entfernt angeordnet sind), erhöht sich auch die Latenzzeit von Signalen, die über eine solche Hardware-Auslöserleitung kommuniziert werden.
  • Eine andere Synchronisationstechnik verwendet eine Software zum Steuern der Operationen der verschiedenen Instrumente auf synchronisierte Weise. Eine solche Software-Synchronisation kann in Situationen verwendet werden, in denen Hardware-Auslöser nicht verfügbar sind, wie z. B. wenn die Instrumente, die synchronisiert werden sollen, zu weit auseinander angeordnet sind, um die Verwendung einer Hardware-Auslöserleitung zu ermöglichen. Beim Implementieren von Software zum Steuern der Synchronisation der Operation verschiedener Instrumente, kann die Software vordefinierte Zeitverzögerungen, abfragen der Instrumente und/oder Softwareinterrupte zum Koordinieren der Aktionen der Instrumente verwenden. Zum Beispiel, nachdem ein erstes Instrument angewiesen wird, eine erste Aktion zu unternehmen, kann die Software in einer externen Steuerung eine spezifische Zeitmenge warten, bevor ein anderes Instrument angewiesen wird, eine gegebene Aktion zu unternehmen, die nach der Fertigstellung der ersten Aktion durchgeführt werden soll. In manchen Fällen kann die Software in der externen Steuerung ein Instrument abfragen, um zu bestimmen, wann es eine gegebene Funktion abgeschlossen hat, so dass die Software bestimmen kann, wann es angemessen ist, die nächste Aktion auszulösen. In bestimmten Fällen können die Instrumente implementiert sein, um ein Signal zu der externen Steuerung zu senden, um ein Softwareinterrupt in der Steuerung zu erzeugen, die z. B. anzeigt, dass ein gegebenes Instrument eine bestimmte Operation abgeschlossen hat.
  • Als ein Beispiel für das Verwenden einer Softwaresynchronisationstechnik beim Synchronisieren von Operationen des oben erwähnten Empfängers und Digitalisierers kann ein Steuerungscomputer eine Meldung zu dem Empfänger senden, die denselben anweist, die Frequenz zu ändern. Es ist bekannt, dass eine bestimmte Wartezeit benötigt wird, bevor die Messung des Signals ausgelöst wird, das die geänderte Frequenz aufweist (um zu ermöglichen, dass die Änderung bei der Frequenz einschwingt). So, nachdem der Empfänger angewiesen wurde, seine Frequenz zu ändern, wartet der Steuerungscomputer (oder „schläft") eine vorbestimmte Zeitspanne, wie z. B. 100 Millisekunden. Der Steuerungscomputer weist dann den Digitalisierer an, das Durchführen einer Messung zu starten.
  • Es sind ebenfalls Techniken zum Synchronisieren der Takte von vernetzten Vorrichtungen bis zu einem hohen Grad an Präzision bekannt. Als ein Beispiel ist ein Netzwerkzeitprotokoll (NTP; NTP = Network Time Protocol) ein Protokoll, das verwendet wird, um Computertaktzeiten in einem Netzwerk aus Computern zu synchronisieren. Gemeinsam mit ähnlichen Protokollen verwendet das NTP eine koordinierte Universalzeit (UTC; UTC = Coordinated Universal Time), um Computertaktzeiten auf innerhalb eine Millisekunde zu synchronisieren und manchmal innerhalb eines Bruchteils einer Millisekunde. Als ein anderes Beispiel hat die Institute of Electrical and Electronics Engineers Standards Association (IEEE-SA) einen neuen Standard genehmigt zum Beibehalten der Synchronität zwischen Takten auf einem Netzwerk, bezeichnet als der IEEE 1588 „Standard for a Precision Synchronization Protocol for Networked Measurement and Control Systems" (Standard für ein Präzisionssynchronisationsprotokoll für vernetzte Mess- und Steuerungs-Systeme). Im Allgemeinen definiert dieser Standard IEEE 1588 Meldungen, die verwendet werden können, um Zeitgebungsinformationen zwischen vernetzten Vorrichtungen auszutauschen, um ihre Takte synchronisiert zu halten. Der Standard IEEE 1588 ermöglicht sogar einen höheren Grad an Präzision (z. B. bis auf innerhalb eine Mikrosekunde) bei der Taktsynchronisation als der, der durch das NTP bereitgestellt wird.
  • Während jedoch Techniken, wie z. B. NTP und der Standard IEEE 1588 Techniken zum Synchronisieren der Takte von vernetzten Vorrichtungen auf einen hohen Präzisionsgrad liefern, derart, dass die vernetzten Vorrichtungen, die jeweils einen lokalen Takt aufweisen, einen gemeinsamen Zeitsinn aufweisen, adressieren diese Techniken nicht die Synchronisation der Operation der Vorrichtungen. Statt dessen konzentrieren sich solche Techniken auf das aktive Beibehalten synchronisierter Takte zwischen vernetzten Vorrichtungen. Somit lassen es die aktiven Taktsynchronisationstechniken offen, wie die Vorrichtungen ihre synchronisierten Takte wirksam einsetzen, falls überhaupt, um ihre jeweiligen Operationen zu synchronisieren.
    •
  • Es ist die Aufgabe der vorliegenden Erfindung, ein System und ein Verfahren mit verbesserten Charakteristika zu schaffen.
  • Diese Aufgabe wird durch ein System gemäß Anspruch 1, 15 und 25 und durch ein Verfahren gemäß Anspruch 28, 32 und 38 gelöst.
  • Die vorliegende Erfindung richtet sich auf ein System und ein Verfahren, die Operationen einer Mehrzahl von Vorrichtungen über Meldungen über ein Kommunikationsnetzwerk synchronisieren. Somit ist eine Mehrzahl von Vorrichtungen kommunikativ über ein Kommunikationsnetzwerk gekoppelt, und die lokalen Takte der Vorrichtungen sind zu einem hohen Präzisionsgrad synchronisiert, unter Verwendung von IEEE 1588, NTP oder einer anderen Technik zum Synchronisieren ihrer lokalen Takte. Ereignismeldungen können gesendet werden, die eine Identifikation eines Ereignisses umfassen, sowie einen Zeitstempel, der auf dem lokalen Takt des Senders basiert. Der Empfänger einer Ereignismeldung kann bestimmen, ob er konfiguriert/programmiert ist, um auf das identifizierte Ereignis hin zu handeln, und wenn er auf das identifizierte Ereignis hin handeln soll, kann er seine Aktion basierend auf dem Zeitstempel unternehmen, der in der Ereignismeldung umfasst ist. Bei bestimmten Ausführungsbeispielen sind die Ereignisse, die eine Aktion und/oder die spezifischen ansprechenden Aktionen auslösen sollen, die für ein gegebenes Ereignis unternommen werden sollen, dynamisch für jede Vorrichtung programmierbar. Wie hierin weiter beschrieben wird, können die Ereignismeldungen verwendet werden, um die Operationen von verschiedenen Vorrichtungen mit einem hohen Grad an zeitlicher Präzision zu koordinieren, da die Aktionen, die an jeder Vorrichtung unternommen werden, auf dem Zeitstempel basieren können, der in der Ereignismeldung umfasst ist.
  • Zum Beispiel weist ein System gemäß zumindest einem Ausführungsbeispiel zumindest zwei Vorrichtungen auf, die kommunikativ über ein Kommunikationsnetzwerk gekoppelt sind, wobei die zumindest zwei Vorrichtungen eine Einrichtung zum Synchronisieren ihrer Takte umfassen. Die Einrichtung zum Synchronisieren ihrer Takte synchronisiert gemäß verschiedenen hierin bereitgestellten Ausführungsbeispielen die lokalen Takte der Vorrichtungen, z. B. durch Austausch von Meldungen zwischen den Vorrichtungen. Solche synchronisierten Takte können beispielsweise gemäß dem IEEE-1588-Standard oder dem NTP-Standard implementiert sein. Die zumindest zwei Vorrichtungen weisen ferner eine Einrichtung zum Kommunizieren mit der anderen der zumindest zwei Vorrichtungen über das Kommunikationsnetzwerk auf, von einer Meldung, die einen Zeitstempel umfasst und ein Ereignis identifiziert. Ferner weisen die zumindest zwei Vorrichtungen eine Einrichtung auf zum Empfangen der Meldung und zum Bestimmen einer Antwortaktion, die ansprechend auf das identifizierte Ereignis unternommen werden soll, wobei eine bestimmte Aktion basierend auf dem Zeitstempel unternommen wird, der in der Meldung umfasst ist. Somit können Operationen der Vorrichtungen basierend auf ihren lokalen synchronisierten Takten koordiniert werden, durch die Verwendung von Ereignismeldungen, die über das Kommunikationsnetzwerk kommuniziert werden.
  • Bei bestimmten Ausführungsbeispielen werden die Ereignismeldungen über das Kommunikationsnetzwerk rundgesendet, z. B. unter Verwendung eines UDP. Somit muss sich der Sender der Ereignismeldung nicht damit befassen, mit welchen anderen Vorrichtung(en) die Meldung gesendet werden soll, und ist sich vielleicht nicht einmal bewusst, welche anderen Vorrichtungen mit dem Kommunikationsnetzwerk gekoppelt sind. Alle Vorrichtungen auf dem Kommunikationsnetzwerk (z. B. einem LAN oder einem Teilnetz eines WAN) können die rundgesendete Ereignismeldung empfangen, und jede Vorrichtung kann bestimmen, ob sie konfiguriert ist, um eine Aktion zu unternehmen, ansprechend auf das identifizierte Ereignis. Wenn eine Empfangsvorrichtung nicht konfiguriert ist, um eine Aktion für das identifizierte Ereignis zu unternehmen, kann sie die rundgesendete Ereignismeldung ignorieren. Natürlich können bei anderen Ausführungsbeispielen die Ereignismeldungen auf eine Nicht-Rundsende-Weise gesendet werden, wie z. B. unter Verwendung eines TCP.
  • Das Vorangehende hat ziemlich umfassend die Merkmale und die technischen Vorteile der vorliegenden Erfindung ausgeführt, so dass die detaillierte Beschreibung der Erfindung, die folgt, besser verständlich ist. Zusätzliche Merkmale und Vorteile der Erfindung werden hierin nachfolgend beschrieben, die den Gegenstand der Ansprüche der Erfindung bilden. Es sollte darauf hingewiesen werden, dass der Entwurf und das spezifische Ausführungsbeispiel, die hierin offenbart sind, ohne weiteres als eine Basis zum Modifizieren oder Entwerfen anderer Strukturen verwendet werden können, um die selben Zwecke der vorliegenden Erfindung auszuführen. Es sollte ferner erkannt werden, dass solche gleichwertigen Entwürfe nicht von der Erfindung abweichen, wie sie in den beiliegenden Ansprüchen ausgeführt ist. Die neuen Merkmale, die als charakteristisch für die Erfindung erachtet werden, sowohl im Hinblick auf die Organisation als auf das Verfahren der Operation, sind zusammen mit weiteren Zielen und Vorteilen aus der nachfolgenden Beschreibung besser verständlich, wenn sie in Verbindung mit den begleitenden Figuren betrachtet wird. Es wird jedoch ausdrücklich darauf hingewiesen, dass jede der Figuren zum Zweck der Darstellung und der Beschreibung vorgelegt wird und nicht als eine Definition der Grenzen der vorliegenden Erfindung gedacht ist.
    •
  • Bevorzugte Ausführungsbeispiele der vorliegenden Erfindung werden nachfolgend Bezug nehmend auf die beiliegenden Zeichnungen näher erläutert. Es zeigen:
  • 1 ein Beispielsystem gemäß einem Ausführungsbeispiel zum Synchronisieren von Operationen einer Mehrzahl von vernetzten Vorrichtungen;
  • 2 ein spezifisches Beispiel zum Verwenden einer meldungsbasierten Technik in dem System aus 1 zum Koordinieren der Operationen der vernetzten Vorrichtungen; und
  • 3 ein Operationsflussdiagramm zum Synchronisieren der Operation einer Mehrzahl von vernetzten Vorrichtungen gemäß einem Ausführungsbeispiel.
  • Wie oben beschrieben wurde, erfordern Messsysteme häufig, dass die Operation verschiedener Instrumente synchronisiert (oder koordiniert) wird, auf eine geeignete Weise, um zu ermöglichen, dass genaue Messungen erhalten werden. Zum Beispiel sollte ein Spektrumanalysator koordiniert werden, um seine Messungen durchzuführen, nachdem eine Signalquelle ausreichend Gelegenheit hatte, bei ihrer Ausgangsfrequenz einzuschwingen.
  • Das gesamte oder ein Abschnitt eines Messsystems kann mit „synthetischen Instrumenten" gebildet sein. Synthetische Instrumente sind nicht in der Lage, Messungen selbst fertigzustellen, sondern statt dessen muss eine Ansammlung derselben zusammenarbeiten, um eine Messung zu implementieren. Andererseits enthalten herkömmliche Alles-in-Einem-Gehäuse-Instrumente (hierin bezeichnet als „vollständig abgeschlossene Instrumente") vollständig alle Teilsysteme, die zum Durchführen einer gewünschten Messung benötigt werden. Zum Beispiel kann ein Spektrumanalysator als ein vollständig abgeschlossenes Instrument implementiert sein, oder ein solcher Spektrumanalysator kann durch eine Sammlung aus synthetischen Instrumenten gebildet werden, wie z. B. einen Empfänger, Digitalisierer etc., die kommunikativ über ein Kommunikationsnetzwerk gekoppelt sind. Ein vollständig abgeschlossenes System muss möglicherweise eine Schnittstelle mit einem anderen System bilden, um etwas zum Messen zu haben. Zum Beispiel bildet ein vollständig abgeschlossener Spektrumanalysator eine Schnittstelle mit einer Quelle, um das Signal zu messen, das durch die Quelle geliefert wird. Egal ob eine Mehrzahl von vollständig abgeschlossenen Instrumenten (z. B. Spektrumanalysator, HF-Quelle etc.) oder eine Mehrzahl von synthetischen Instrumenten (oder eine Kombination von vollständig abgeschlossenen und synthetischen Instrumenten) verwendet wird, ist es häufig erwünscht, dass die relativen Operationen der verschiedenen Instrumente auf eine bestimmte Weise koordiniert werden, um genaue Messungen zu ermöglichen.
  • Innerhalb der traditionellen, vollständig abgeschlossenen Instrumente können verschiedene Teilsysteme Zeitgebungs- und Synchronisations-Funktionen über Hardware-Auslöserleitungen (hardware trigger line) und/oder ihre zugrundeliegende Firmware erreichen. Synthetische Instrumente, die Funktionsteile der vollständig abgeschlossenen Instrumente sind, müssen möglicherweise auf eine andere Weise synchronisiert werden, da z. B. solche synthetischen Instrumente zu weit auseinander angeordnet sein können, als dass eine Verwendung von Hardware-Auslöserleitungen praktisch ist, und/oder die Verdrahtungskomplexitäten, die in das Implementieren solcher Hardware-Auslöserleitungen involviert sind, können diese Lösung unerwünscht machen. Zusätzlich dazu sind die Anforderungen zur Synchronisation synthetischer Instrumente häufig strenger als für die Synchronisation zwischen separaten vollständig abgeschlossenen Instrumenten, aufgrund der Tatsache, dass jedes synthetische Instrument (oder „Modul") einen kleineren Funktionalitätssatz enthält.
  • Bezug nehmend wiederum auf das oben erwähnte Beispiel eines Spektrumanalysators umfassen moderne, vollständig abgeschlossene Spektrumanalysatoren üblicherweise einen Empfänger und einen Digitalisierer. Die Firmware des Spektrumanalysators steuert die Frequenzwobbelung des Empfängers sowie des Digitalisierers und kann ohne weiteres die Digitalisierer- mit der Empfänger-Frequenz synchronisieren, um sicherzustellen, dass Messungen korrekt durchgeführt werden. Ein synthetisches Instrumentsystem andererseits könnte einen Empfänger und einen Digitalisierer umfassen, aber nicht in dem selben Instrument. Eine Synchronisation zwischen diesen Vorrichtungen ist daher nicht in einem einzelnen Instrument enthalten. Bei diesem synthetischen Instrumentsystem ist eine Synchronisation der Digitalisierer- mit der Empfänger-Frequenz erwünscht, um sicherzustellen, dass der Digitalisierer Messungen zu der Zeit durchführt, zu der die Empfängerfrequenz eingeschwungen ist, und nicht früher oder später als das. Techniken werden hierin bereitgestellt, die zum Synchronisieren der Operationen einer Mehrzahl von synthetischen Instrumenten und/oder vollständig abgeschlossenen Instrumenten verwendet werden können.
  • Bezug nehmend auf 1 ist ein Beispielsystem 10 gemäß einem Ausführungsbeispiel zum Synchronisieren von Operationen einer Mehrzahl von vernetzten Vorrichtungen (oder „Instrumenten") gezeigt. Das Beispielsystem 10 umfasst eine Steuerung 11, eine Quelle 12 und einen Empfänger 13, die alle kommunikativ über ein Kommunikationsnetzwerk 14 gekoppelt sind, das ein lokales Netz (LAN; LAN = local area network), das Internet oder ein anderes weites Netz (WAN; WAN = wide area network), ein öffentliches Telefonnetzwerk (PSTN; PSTN = public switched telephony network), ein drahtloses Netz, eine Kombination der Vorangehenden und/oder ein anderes Netz sein kann, das bereits bekannt ist oder später entwickelt wird, zum Kommunizieren von Informationen von zumindest einer Vorrichtung zu zumindest einer anderen Vorrichtung. Während eine Quelle 12 und ein Empfänger 13 bei diesem Beispiel gezeigt sind, wird darauf hingewiesen, dass Ausführungsbeispiele zum Synchronisieren von Operationen, die hierin beschrieben sind, nicht in ihrer Anwendung auf diese exemplarischen Instrumente eingeschränkt sind. Die hierin beschriebenen Techniken können zum Synchronisieren der Operationen von Instrumenten verwendet werden, die ein Messsystem bilden. Solche Techniken können zum Synchronisieren der Operationen von synthetischen Instrumenten eines Messsystems und/oder vollständig abgeschlossenen Instrumenten eingesetzt werden. Ferner, während die Techniken eine bestimmte Anwendbarkeit an Messsystemen aufweisen, um die Operationen von verschiedenen Instrumenten zu einem hohen Grad an Präzision zu synchronisieren, die zum Durchführen von Messungen verwendet werden, können die hierin beschriebenen Techniken auf ähnliche Weise in anderen Typen von Systemen eingesetzt werden, in denen die Synchronisation von Operationen einer Mehrzahl von vernetzten Vorrichtungen erwünscht ist.
  • Die Steuerung 11, die ein Personalcomputer (PC) oder eine andere prozessorbasierte Vorrichtung sein kann, umfasst eine zentrale Verarbeitungseinheit (CPU; CPU = central processing unit) 105A. Auf ähnliche Weise umfasst die Quelle 12 eine CPU 105B und der Empfänger 13 umfasst eine CPU 105C. Die Takte von jedem Element aus Steuerung 11, Quelle 12 und Empfänger 13 sind bei diesem Beispiel synchronisiert. Bei diesem spezifischen Beispiel wird das IEEE 1588 verwendet, wobei die Steuerung 11 den IEEE-1588-Takt 103A implementiert, die Quelle 12 den IEEE-1588-Takt 103B implementiert und der Empfänger 13 den IEEE-1588-Takt 103C implementiert. Natürlich können andere Techniken zum aktiven Synchronisieren der lokalen Takte, wie z. B. unter Verwendung von NTP, bei anderen Implementierungen verwendet werden. Die lokalen Takte werden derart bezeichnet, dass sie „aktiv synchronisiert" sind, da die Vorrichtungen miteinander in Wechselwirkung sind, um ihre jeweiligen lokalen Takte synchronisiert zu halten, gemäß der bestimmten verwendeten Synchronisationstechnik (z. B. IEEE 1588 oder NTP). Andere Techniken (z. B. passive Techniken) können bei alternativen Ausführungsbeispielen zum Synchronisieren der lokalen Takte verwendet werden, unter Verwendung von GPS-Empfängern (GPS = global positioning system), etc. Somit haben die Steuerung 11, die Quelle 12 und der Empfänger 13 ihre lokalen Takte 103A, 103B und 103C zu einem hohen Präzisionsgrad derart synchronisiert, dass sie alle einen gemeinsamen Zeitsinn aufweisen. Wie hierin weiter beschrieben wird, muss die der lokale Takt der Steuerung 11 bei bestimmten Ausführungsbeispielen nicht mit den Takten der anderen Instrumente in dem Messsystem synchronisiert sein, wie z. B. dem der Quelle 12 und des Empfängers 13.
  • Die Steuerung 11, die Quelle 12 und der Empfänger 13 weisen jeweils einen Ereignisverwalter auf, der auf denselben ausgeführt wird, etikettiert als 101A, 101B bzw. 101C. Im Allgemeinen ist der Ereignisverwalter eine Software und/oder Hardware, die entworfen ist, um es den verschiedenen Instrumenten zu ermöglichen, Informationen über zeitempfindliche Ereignisse zu kommunizieren. Die Operation des Ereignisverwalters gemäß diesem beispielhaften Ausführungsbeispiel wird nachfolgend weiter beschrieben.
  • Bevor mit der Erörterung des Beispielsystems 10 aus 2 fortgefahren wird, ist es hilfreich, kurz einen Teil der Terminologie zu erörtern, die hierin verwendet wird.
  • Der Ausdruck „Ereignis", wenn er alleine verwendet wird, bezieht sich auf etwas, das innerhalb eines Instruments passiert, wie z. B. in der Quelle 12 oder in dem Empfänger 13 des Beispielsystems 10. Zum Beispiel könnte ein Ereignis erzeugt werden, wenn sich der Eingabepuffer eines Digitalisierers füllt, oder wenn ein Ausgangssignal eingeschwungen ist. Ereignisse werden üblicherweise durch die Hardware eines Instruments erzeugt, obwohl dies keine Einschränkung ist. Software kann ebenfalls Ereignisse erzeugen.
  • Der Ausdruck „Ereignismeldung" bezieht sich auf eine Meldung, die auf dem Kommunikationsnetzwerk gesendet wird, die verwendet wird, um andere Instrumente zu benachrichtigen, dass ein Ereignis aufgetreten ist. Bei bestimmten hierin gelieferten Ausführungsbeispielen werden Ereignismeldungen z. B. unter Verwendung eines Benutzerdatagrammprotokolls (UDP; UDP = User Datagram Protocol) zu allen Instrumenten auf einem gegebenen Kommunikationsnetzwerk (z. B. auf einem gegebenen Teilnetz) rundgesendet. Bei anderen Ausführungsbeispielen werden die Ereignismeldungen über ein Punkt-zu-Punkt-Protokoll gesendet, wie z. B. das Sendesteuerungsprotokoll (TCP; TCP = Transmission Control Protocol). Ein Instrument kann eine Ereignismeldung senden. Andere Instrumente können entweder auf Ereignismeldungen antworten oder dieselben ignorieren.
  • Der Ausdruck „Ausgabeereignis" bezieht sich auf ein Ereignis, das zu einer Ereignismeldung führt, die auf dem Kommunikationsnetzwerk kommuniziert wird. Es wird darauf hingewiesen, dass nicht alle Ereignisse Ausgabeereignisse sind. Ein Instrument kann einige Ereignisse intern handhaben.
  • Der Ausdruck „Eingabeereignis" bezieht sich auf ein Ereignis, das von einem anderen Instrument empfangen wird. Das Eingabeereignis kommt in der Form einer Ereignismeldung auf dem Kommunikationsnetzwerk an.
  • Der Ausdruck „Aktion" bezieht sich auf etwas, das ein Instrument entweder ansprechend auf ein Ereignis oder auf eine Ereignismeldung durchführt. Bei bestimmten hierin vorgesehenen Ausführungsbeispielen werden Aktionen mit Hilfe von Rückrufroutinen ausgeführt. In diesem Kontext ist eine Aktion kein atomares Ereignis, z. B. kann eine Rückrufroutine eine komplexe Anweisungssequenz ausführen.
  • Der Ausdruck „Programmierungsmeldung" bezieht sich auf eine Meldung, die auf dem Kommunikationsnetzwerk gesendet wird, die verwendet wird, um eine Empfängervorrichtung zu programmieren, um eine bestimmte Aktion zu unternehmen, ansprechend auf die Erfassung eines bestimmten Ereignisses.
  • Gemäß den hierin beschriebenen Ausführungsbeispielen werden Ereignismeldungen über das Kommunikationsnetzwerk 14 gesendet, um die Operationen der Instrumente zu koordinieren, wie z. B. der Quelle 12 und des Empfängers 13. Somit, anstelle Hardware-Auslöserleitungen zwischen allen Instrumenten zu benötigen, die in einem Messsystem verwendet werden, werden zumindest bestimmte Instrumente unter Verwendung der hierin beschriebenen meldungs-basierten Technik synchronisiert. Gemäß zumindest einem Ausführungsbeispiel umfassen die Ereignismeldungen die Identifikation eines Ereignisses sowie einen entsprechenden Zeitstempel. Die Instrumente können konfiguriert/programmiert werden, um eine bestimmte Aktion daraufhin zu unternehmen, dass das Synchronisationsmodul ein gegebenes Ereignis empfängt, das entweder ein Ereignis sein kann, das intern empfangen wird, oder ein Ereignis, das in einer Ereignismeldung umfasst ist (ein „Eingangsereignis"). Wie ferner hierin beschrieben wird, sind bei bestimmten Ausführungsbeispielen die Aktionen dynamisch programmierbar. Zum Beispiel kann die Steuerung 11 eine Programmierungsmeldung zu der Quelle 12 senden, die ihren Ereignisverwalter 101B anweist, eine bestimmte Aktion zu unternehmen, nach der Erfassung eines bestimmten Ereignisses. Bei bestimmten Ausführungsbeispielen kann die Quelle 12 vorkonfiguriert sein, um die gewünschte Aktion ansprechend auf ein gegebenes Ereignis zu unternehmen, und ist nicht diesbezüglich dynamisch programmiert. Somit, da die Instrumente programmiert sind (oder anderweitig konfiguriert sind), um entsprechende Aktionen ansprechend auf erfasste Ereignisse zu unternehmen, können Ereignismeldungen, die Ereignisse und entsprechende Zeitstempel identifizieren (gemäß den synchronisierten lokalen Takten der Instrumente), zum Koordinieren der entsprechenden Operationen der Instrumente verwendet werden, wie hierin weiter beschrieben wird.
  • Bei dem Ausführungsbeispiel aus 1 umfassen die Steuerung 11, die Quelle 12 und der Empfänger 13 jeweils programmierte Ereignisinformationen, bezeichnet als 102A, 102B bzw. 102C. Solche programmierten Ereignisinformationen können z. B. die Aktion(en) spezifizieren, die das entsprechende Instrument laut Konfiguration ansprechend auf die spezifizierten Ereignisse unternimmt. Die programmierten Ereignisinformationen können z. B. als eine Datenbank angeordnet sein oder auf eine andere geeignete Weise gespeichert werden. Bei bestimmten Ausführungsbeispielen ist eine Benutzerschnittstelle 104 auf der Steuerung 11 vorgesehen, um einem Benutzer 15 zu ermöglichen, mit dem Ereignisverwalter 101A in Wechselwirkung zu treten, z. B. um die Ereignisinformationen auf den verschiedenen Instrumenten zu programmieren. Beispiele solcher programmierten Ereignisinformationen 102A–102C werden hierin weiter beschrieben, einschließlich dem spezifischen Beispiel, das in Tabelle 2 unten enthalten ist.
  • Da die lokalen Takte der Instrumente zu einem hohen Präzisionsgrad synchronisiert sind, können die Aktionen der verschiedenen vernetzten Instrumente mit einem solchen hohen Grad an Präzision koordiniert werden. Während ein meldungs-basierter Lösungsansatz zum Koordinieren der Operationen der Instrumente verwendet werden kann, können ihre Operationen mit einem höheren Grad an Präzision koordiniert werden, als durch die Meldung bereitgestellt wird (z. B. aufgrund von Latenzzeiten, die beim Senden der Meldungen über das Kommunikationsnetzwerk 14 angetroffen werden können etc.), da die Instrumente ihre lokalen Takte aktiv auf einen hohen Präzisionsgrad synchronisiert haben.
  • Es sei z. B. angenommen, dass die Quelle 12 konfiguriert/programmiert ist, um ihre Ausgangsfrequenz ändert (z. B. HF-Frequenz) zu ändern, ansprechend darauf, dass das „Ereignis Nr.1" erfasst wird, und sobald die Frequenzänderung eingeschwungen ist, die Quelle 12 dann eine Ereignismeldung ausgibt, die „Ereignis Nr.2" identifiziert. Es sei ferner angenommen, dass der Empfänger 13 konfiguriert/programmiert ist, um eine Messung des Signals durchzuführen (z. B. Leistung und/oder andere Charakteristika des Signals), ansprechend auf das erfassen von Ereignis Nr.2. Der Benutzer 15 kann bei bestimmten Implementierungen den Messprozess initiieren, durch eine Wechselwirkung, über die Benutzerschnittstelle 104, mit der Steuerung 11, um zu verursachen, dass ein Ereignis Nr.1 zu der Quelle 12 gesendet wird. Wie hierin weiter beschrieben wird, kann ein solches Ereignis Nr.1 bei bestimmten Implementierungen über das Kommunikationsnetzwerk 14 rundgesendet werden. Der Ereignisverwalter 101B auf Quelle 12 würde das Ereignis Nr.1 erfassen und gemäß der entsprechenden programmierten Aktion, die in den programmierten Ereignisinformationen 102B für dieses Ereignis Nr.1 identifiziert ist, seine Frequenz ändern und nachfolgend eine Ereignismeldung zu dem Empfänger 13 senden, die das Ereignis Nr.2 identifiziert. Wiederum kann bei bestimmten Implementierungen diese Ereignismeldung, die durch die Quelle gesendet wird, über das Kommunikationsnetzwerk 14 rundgesendet werden. Die Ereignismeldung umfasst ferner einen Zeitstempel, basierend auf dem lokalen Takt 103B der Quelle, der dem entspricht, wann die geänderte Frequenz eingeschwungen ist (und somit bereit zur Messung ist).
  • Der Empfänger 13 empfängt die Ereignismeldung, die das Ereignis Nr.2 identifiziert, und den entsprechenden Zeitstempel, und somit kann der Empfänger 13 seine programmierte Aktion auszuführen, ansprechend auf das Ereignis Nr.2, basierend auf dem entsprechenden Zeitstempel in der Ereignismeldung. Zum Beispiel kann der Empfänger 13 programmiert sein, um die Messung an dem Zeitstempel zu nehmen, der in der empfangenen Ereignismeldung umfasst ist, und diese Messung zu der Steuerung 11 zu senden, ansprechend auf das erfassen eines Ereignisses Nr.2. Obwohl der Empfänger 13 die Ereignismeldung empfängt, nach dem Zeitstempel, der bei diesem Beispiel in der Ereignismeldung umfasst war, kann der Empfänger, wenn der Empfänger 13 kontinuierlich Messungen durchführt und dieselben puffert, aus seinem Puffer die Messung wiedergewinnen, die dem Zeitstempel entspricht, der in der Meldung umfasst ist, und diese Messung zu der Steuerung 11 senden. Somit empfängt die Steuerung 11 die Messung, die dem exakten Zeitstempel entspricht, der in der Ereignismeldung umfasst ist, von der Quelle 12 zu dem Empfänger 13. Wenn die Ereignismeldung von der Quelle 12 zu dem Empfänger 13 zu einem solchen Ausmaß verzögert wurde, dass der Empfänger 13 in seinem Puffer die Messung nicht mehr hat, die dem Zeitstempel entspricht, der in der Ereignismeldung umfasst ist, kann der Empfänger 13 z. B. einen Fehler erzeugen.
  • Als ein anderes Beispiel könnte der Empfänger 13 programmiert sein, um auf die Erfassung des Ereignisses Nr.2 zu antworten, durch Durchführen einer Messung zu einer Zeitperiode nachfolgend zu dem Zeitstempel, der in der empfangenen Ereignismeldung umfasst ist, wie z. B. 2 Sekunden nach dem Zeitstempel, der in der empfangenen Ereignismeldung umfasst ist, und dann diese Messung zu der Steuerung 11 sendet. Angenommen, dass die Ereignismeldung erzeugt und über das Kommunikationsnetzwerk 14 innerhalb von 2 Sekunden von dem Zeitstempel kommuniziert werden kann, der in der Meldung umfasst ist, kann der Empfänger diese Meldung empfangen und seine Messung entsprechend durchführen (oder die entsprechende Messung aus seinem Puffer wiedergewinnen, wenn er kontinuierlich Messungen durchführt). Somit kann der Empfänger 13 seine Messung zu einer Zeit relativ zu dem Zeitstempel durchführen, der in der Ereignismeldung umfasst ist, im Gegensatz zu der Zeit, zu der der Empfänger die Ereignismeldung empfängt. Dementsprechend können die Operationen der Quelle 12 und des Empfängers 13 gemäß dem Zeit stempel koordiniert werden, der in der Ereignismeldung umfasst ist, und ein solcher Zeitstempel basiert auf dem synchronisierten Takt des Senders der Meldung, d. h. der Quelle bei den obigen Beispielen, und ist nicht auf Synchronisationsoperationen beschränkt, basierend auf der Zeit, zu der die Meldungen empfangen werden (die basierend auf Netzwerklatenzzeiten variieren kann).
  • Bezug nehmend auf 2 ist ein spezifisches Beispiel zum Verwenden einer meldungsbasierten Technik in System 10 (aus 1) zum Koordinieren der Operationen der vernetzten Instrumente gezeigt. Bei dem Beispiel aus 2 wird die Steuerung 11 verwendet, um die Quelle 12 bei Operationsblock 201 zu programmieren. Zum Beispiel kann der Benutzer 15 mit der Benutzerschnittstelle 104 in Wechselwirkung treten, um bestimmte Informationen zu spezifizieren, gemäß denen die Quelle 12 programmiert werden soll. Bei diesem Beispiel wird die Quelle 12 programmiert, um ihre Frequenz bei 1:00:00 zu ändern und dann ein Rundsenden einer Ereignismeldung durchzuführen, die Ereignis #1 identifiziert. Somit werden diese Informationen (über eine Programmierungsmeldung) durch die Quelle 12 von der Steuerung 11 empfangen und in ihren programmierten Ereignisinformationen 102B gespeichert. Das Planen, dass ein Ereignis zu einer absoluten Zeit oder zu einer relativen Zeit auftritt (z. B. eine Zeit, die in Bezug auf eine andere Zeit spezifiziert ist, wie z. B. „10 Sekunden nach dem Zeitstempel, der in einer Ereignismeldung umfasst ist, die Ereignis X identifiziert") auf diese Weise kann als das Einstellen einer „Zeitbombe" bezeichnet werden, die eine absolute oder relative Detonationszeit aufweist, wobei nach der Detonation einer solchen Zeitbombe die entsprechende Vorrichtung, für die die Zeitbombe eingestellt wurde (Quelle 12 bei diesem Beispiel) eine programmierte Aktion unternimmt (Ändern ihrer Frequenz bei diesem Beispiel). Ein Beispiel zum Implementieren solcher Zeitbomben und zum Verwenden derselben zum Koordinieren von Operationen von vernetzten Vorrichtungen wird weiter beschrieben in der gleichzeitig eingereichten und gemeinsam zugewiesenen deutschen Patentanmeldungen Anwaltsaktenzeichen AG050618PDE mit dem Titel „SYSTEM UND VERFAHREN ZUM KOORDINIEREN DER AKTIONEN EINER MEHRZAHL VON VORRICHTUNGEN ÜBER EIN PLANEN DER AKTIONEN BASIEREND AUF SYNCHRONISIERTEN LOKALEN TAKTEN", deren Offenbarung hierin durch Bezugnahme aufgenommen ist.
  • Die Steuerung 11 wird verwendet, um den Empfänger bei dem Operationsblock 202. Zum Beispiel kann der Benutzer 15 mit der Benutzerschnittstelle 104 in Wechselwirkung treten, um bestimmte Informationen zu spezifizieren, gemäß denen der Empfänger programmiert werden soll. Bei diesem Beispiel ist der Empfänger 13 programmiert, um eine Messung auszuführen, wenn Ereignis Nr.1 erfasst wird, und dann ein Rundsenden einer Ereignismeldung durchzuführen, die Ereignis Nr.2 identifiziert. Somit werden diese Informationen durch den Empfänger 13 von der Steuerung 11 empfangen und in seine programmierten Ereignisinformationen 102C gespeichert.
  • Ferner wird bei diesem Beispiel die Steuerung 11 selbst programmiert, bei Block 203, um bestimmte Ereignisse zu erfassen und Antwortaktionen zu unternehmen. Zum Beispiel kann der Benutzer 15 mit der Benutzerschnittstelle 104 in Wechselwirkung treten, um bestimmte Informationen zu spezifizieren, gemäß denen die Steuerung 11 programmiert werden soll. Bei diesem Beispiel ist die Steuerung 11 programmiert, um Messdaten aus dem Empfänger 13 zu lesen, wenn Ereignis Nr.2 erfasst wird, und dann die gelesenen Daten anzuzeigen. Somit werden diese Informationen durch die Steuerung 11 empfangen und in ihre programmierten Ereignisinformationen 102A gespeichert.
  • Bei 1:00:00 detoniert die Zeitbombe, die an der Quelle 12 wird, wodurch verursacht wird, dass die Quelle 12 ihre Frequenz ändert eine Ereignismeldung erzeugt, die Ereignis Nr.1 identifiziert, was als Operationsblock 204 in 2 gezeigt ist. Wie oben erwähnt wurde, umfasst die Ereignismeldung ferner einen entsprechenden Zeitstempel basierend auf dem lokalen Takt 103B der Quelle 12. Bei diesem Beispiel führt die Quelle 12 ein Rundsenden der Ereignismeldung über das Kommunikationsnetzwerk 14 unter Verwendung eines UDP oder eines anderen geeigneten Gruppenrufprotokolls durch. Techniken, die bei bestimmten Ausführungsbeispielen zum Verwenden eines „unzuverlässigen" Protokolls eingesetzt werden können, wie z. B. UDP, auf eine Weise, die die Zuverlässigkeit erhöht, wie z. B. erwünscht sein kann, wenn die Meldungen, die auf diese Weise kommuniziert werden, eine Basis zum Koordinieren von Operationen zwischen vernetzten Instrumenten darstellen, werden ferner in der gleichzeitig eingereichten und gemeinsam zugewiesenen deutschen Patentanmeldung Anwaltsaktenzeichen Nr. AG050620PDE mit dem Titel „SYSTEM UND VERFAHREN ZUR STABILEN KOMMUNIKATION ÜBER EIN UNZUVERLÄSSIGES PROTOKOLL" beschrieben, deren Offenbarung hierin durch Bezugnahme aufgenommen ist.
  • Somit führt der Ereignisverwalter 101B der Quelle 12 ein Rundsenden einer Ereignismeldung durch, die das Ereignis Nr.1 identifiziert und die einen entsprechenden Zeitstempel umfasst, der auf dem lokalen Takt 103B basiert. Zum Beispiel kann der Zeitstempel die Zeit 1:00:01 sein, die der Zeit entspricht, zu der die geänderte Frequenz eingeschwungen ist. Es sollte darauf hingewiesen werden, dass die Quelle 12 programmiert werden könnte, um die Meldung zu der Zeit zu senden, zu der sie das Ändern ihrer Frequenz beginnt, und der Zeitstempel, der in der Ereignismeldung umfasst ist, kann daher der Zeit entsprechen, zu der die Quelle die Frequenzänderung beginnt, wobei in diesem Fall der Empfänger 13 programmiert sein kann, um seine Messung zu einer verzögerten Zeit relativ zu dem umfassten Zeitstempel ausführt, um zu erlauben, dass die Frequenz einschwingt. Auf diese Weise kann die Ereignismeldung auf dem Weg zu dem Empfänger sein, während die Frequenzänderung an der Quelle auftritt, was zu einer verbesserten Effizienz bei der Messung führen kann.
  • Das rundgesendete Ereignis Nr.1 wird durch den Ereignisverwalter 101A der Steuerung 11 erfasst, und bei dem Operationsblock 205 bestimmt ein solcher Ereignisverwalter 101A der Steuerung 11, dass keine Antwortaktion durch die Steuerung 11 benötigt wird. Das heißt, die Steuerung 11 wurde nicht programmiert, um eine Antwortaktion auf ein empfangenes Ereignis Nr.1 auszuführen, und somit ignoriert der Ereignisverwalter 101A die Ereignismeldung, die durch die Quelle 12 rundgesendet wurde.
  • Auf ähnliche Weise wird das rundgesendete Ereignis Nr.1 durch den Ereignisverwalter 101C des Empfängers 13 erfasst. Da der Empfänger 13 programmiert wird (siehe Operationsblock 202), um eine Messung durchzuführen, auf das Empfangen von Ereignis Nr.1 hin, bei Operationsblock 407, verursacht der Ereignisverwalter 101C des Empfängers 13, dass eine solche Antwortaktion durch den Empfänger 13 unternommen wird. Wie oben erörtert wurde, kann der Empfänger 13 programmiert werden, um seine Messung an dem Zeitstempel durchzuführen, der in der Ereignismeldung umfasst ist (wobei der Empfänger 13 eine gepufferte Messung wiedergewinnen kann, die er bei einem solchen Zeitstempel durchgeführt hat), oder der Empfänger 13 kann programmiert werden, um seine Messung bei einem programmierten Zeitintervall von dem Zeitstempel durchzuführen, der in der Ereignismeldung umfasst ist, um Beispiele zu nennen.
  • So wie der Empfänger 13 bei Operationsblock 207 programmiert wurde, um Block 202 auszuführen, führt der Empfänger 13 ein Rundsenden einer Ereignismeldung durch, die Ereignis Nr.2 identifiziert und die einen entsprechenden Zeitstempel basierend auf ihrem lokalen Takt 103C umfasst. Das rundgesendete Ereignis Nr.2 wird durch den Ereignisverwalter 101B der Quelle 12 erfasst, und bei Operationsblock 208 bestimmt ein solcher Ereignisverwalter 101B der Quelle 12, dass keine Antwortaktion durch die Quelle 12 benötigt wird. Das heißt, die Quelle 12 wurde nicht programmiert, um eine Antwortaktion auf ein empfangenes Ereignis Nr.2 hin auszu führen, und somit ignoriert der Ereignisverwalter 101B die Ereignismeldung, die durch den Empfänger 13 rundgesendet wurde.
  • Die rundgesendete Meldung Ereignis Nr.2 wird ebenfalls durch den Ereignisverwalter 101A der Steuerung 11 erfasst. Da die Steuerung 11 programmiert ist (siehe Operationsblock 203), die Messdaten aus dem Empfänger 13 zu lesen und solche Daten nach dem Empfangen von Ereignis Nr.2 bei Betriebsblock 209 anzuzeigen, verursacht der Ereignisverwalter 101A der Steuerung 11, dass eine solche Antwortaktion durch die Steuerung 11 unternommen wird. Somit liest die Steuerung 11 die Messdaten aus dem Empfänger 13. Zum Beispiel können die Messdaten, die durch den Empfänger 13 gemäß dem Zeitstempel der Ereignismeldung erfasst werden, die der Empfänger 13 von der Quelle 12 empfangen hat, an einer bestimmten Speicheradresse in dem Empfänger 13 gespeichert werden, und die Steuerung 11 kann diese bestimmte Speicheradresse des Empfängers bei Block 411 lesen. Als ein weiteres Beispiel kann die Ereignismeldung, die durch den Empfänger 13 erzeugt wird, einen Zeitstempel umfassen, an dem seine Messung durchgeführt wurde (z. B. entweder denselben Zeitstempel, der in der Ereignismeldung umfasst ist, die von der Quelle 12 zu dem Empfänger 13 gesendet wurde, oder einen Zeitstempel, der ein bestimmtes Intervall von dem Zeitstempel entfernt ist, der in der Ereignismeldung umfasst ist, die von der Quelle 12 zu dem Empfänger 13 gesendet wurde), und die Steuerung 11 kann den Empfänger 13 nach seiner Messung entsprechend dem Zeitstempel abfragen, an dem eine solche Messung bei Block 209 durchgeführt wurde. Dann zeigt bei Block 2210 die Steuerung 11 die gelesenen Messdaten an.
  • Bei dem obigen Beispiel empfängt die Steuerung 11 die Ereignismeldung nicht, die Ereignis Nr.2 identifiziert, bis zu einer bestimmten Zeit nachdem die Messung durch den Empfänger 13 durchgeführt wird, und die Steuerung 11 liest solche Messdaten nicht und zeigt dieselben nicht an, bis sogar zu einer noch späteren Zeit. Aufgrund der Verwendung der Zeitstempel der synchronisierten Takte in den Ereignismeldungen jedoch kann sichergestellt werden, dass die Steuerung 11 die geeigneten Messdaten anzeigt. Zum Beispiel, wenn der Empfänger 13 seine Messung bei 1:00:01 durchgeführt hat, kann sichergestellt werden, dass die Steuerung die Messdaten anzeigt, die bei 1:00:01 erfasst wurden, obwohl die Steuerung 11 die Messdaten z. B. bis 1:00:05 nicht empfangen und anzeigen kann.
  • Natürlich ist die Anwendung der Ausführungsbeispiele, die hierin zum Synchronisieren der Operationen der Vorrichtungen vorgesehen sind, nicht auf das spezifische Beispiel aus 2 beschränkt.
  • Wie das obige Beispiel darstellt, ist der Ereignisverwalter 101A–101C (1) auf der IEEE-1588-Funktionalität für synchronisierte Takte aufgebaut, geht jedoch auch über IEEE 1588 hinaus, durch Ermöglichen, dass zufällige asynchrone Ereignisse erzeugt und zu anderen Instrumenten rundgesendet werden. Bei bestimmten Ausführungsbeispielen kann jedes Instrument in einem System in der Lage sein, eine Ereignismeldung auf dem Netzwerk rund zu senden, immer wenn ein Ereignis passiert. Die Liste von Ereignissen, die auf jedem Instrument auftreten können, können von Instrument zu Instrument variieren, und bei einigen Ausführungsbeispielen sind die Aktionen auf jedem Instrument programmierbar. Zum Beispiel könnte eine Quelle programmiert sein, um eine Ereignismeldung rundzusenden, immer wenn das Ausgangssignal nach einer Frequenzänderung eingeschwungen ist, wie z. B. bei Operationsblock 204 bei dem obigen Beispiel aus 2, oder ein Digitalisierer könnte eine Ereignismeldung senden, immer wenn sein Eingabepuffer voll ist. Der Satz an durchführbaren Ereignissen kann somit spezifisch für jedes Instrument definiert werden.
  • Um Ereignismeldungen bei bestimmten Ausführungsbeispielen zu empfangen, ist jedes Instrument in der Lage, sich an Ereignismeldungen zu „beteiligen". Das heißt, jedes Instrument sollte in der Lage sein, nach Ereignismeldungen zu hören, die durch andere Instrumente rundgesendet werden (über ihren entsprechenden Ereignisverwalter), und entsprechend auf dieselben zu antworten (oder dieselben zu ignorieren).
  • Es sei z. B. angenommen, dass eine Messung durchgeführt wird, die einen Aufwärtswandler benötigt, um eine Frequenz zu ändern. Der Aufwärtswandler muss einschwingen, bevor der Digitalisierer Daten lesen kann. Der Aufwärtswandler weist eine eingebaute Fähigkeit auf, ein internes Ereignis zu erzeugen (wahrscheinlich ein Interrupt), immer wenn das Ausgangssignal einschwingt. Unter Verwendung eines Ereignisverwalters, der für einen solchen Aufwärtswandler und Digitalisierer implementiert ist, könnte dies über die nachfolgende Sequenz erreicht werden:
    • 1. Der Benutzer sendet einen Befehl von einem Steuerungs-PC zu dem Aufwärtswandler, der den Aufwärtswandler programmiert, um auf das Ereignis „Signal eingeschwungen" zu antworten, was ein internes Ereignis ist, das in dem Aufwärtswandler vorab definiert wurde. Als Teil des Konfigurierens dieses Ereignisses spezifiziert der Benutzer eine Rückrufroutine. Diese Routine wird gerufen, immer wenn das Ereignis „Signal eingeschwungen" auftritt, und ist verantwortlich für das Rundsenden einer Ereignismeldung zu anderen Instrumenten auf dem Netzwerk.
    • 2. Der Benutzer programmiert den Digitalisierer, um auf die Ereignismeldung „Signal eingeschwungen" von dem Aufwärtswandler zu antworten. Wiederum wird eine Rückrufroutine spezifiziert. In diesem Fall ist die Rückrufroutine verantwortlich für das Starten einer Messung in dem Digitalisierer.
    • 3. Der Benutzer sendet einen Befehl zu dem Aufwärtswandler, um die Frequenz zu ändern.
    • 4. Wenn das Ausgangssignal des Aufwärtswandlers eingeschwungen ist, wird ein internes Ereignis erzeugt und die Rückrufroutine des Aufwärtswandlers wird gerufen. Dies führt dazu, dass eine Ereignismeldung auf dem Netzwerk rundgesendet wird. Die Meldung umfasst einen Ereignisidentifizierer (z. B. „Signal auf dem Aufwärtswandler Nr.1 eingeschwungen") und einen Zeitstempel.
    • 5. Die Meldung wird durch den Digitalisierer empfangen und syntaktisch analysiert, um zu bestimmen, ob die Meldung relevant ist oder nicht. Da der Digitalisierer programmiert wurde, um auf diese Meldung zu antworten, wird die Rückrufroutine ausgeführt und eine Messung wird begonnen.
  • Es ist wichtig, darauf hinzuweisen, dass die Ereignismeldungen mit einem Zeitstempel unter Verwendung des IEEE-1588-Takts versehen werden. Dies ermöglicht dem Empfangsinstrument, seine Antwort, falls nötig, einzustellen. In dem Fall eines Digitalisierers mit einem Ringmesspuffer ermöglicht es z. B., dass Daten zu der exakten Zeit des Originalereignisses (oder sogar früher) gespeichert werden, sogar wenn Netzwerklatenzzeiten die Ankunft der Ereignismeldung verzögern.
  • Es sollte darauf hingewiesen werden, dass die Operation von verschiedenen vernetzten Instrumenten koordiniert werden kann, basierend auf Ereignissen, die in den Vorrichtungen auftreten, durch Erzeugen von Meldungen, die ein Ereignis identifizieren und einen Zeitstempel umfassen. Natürlich, wie das Beispiel aus 2 darstellt, kann der ereignisbasierte Lösungsansatz mit einem zeitbasierten Lösungsansatz kombiniert werden (der z. B. Zeitbomben zum Planen verwendet, dass Ereignisse zu geplanten Zeiten auftreten, entwe der zu absoluten oder relativen Zeiten). Zum Beispiel können zusätzlich zu instrumentspezifischen Ereignissen Instrumente implementiert werden, um „Zeitbomben" zu unterstützen. Dies ermöglicht dem Benutzer, die Zeit zu definieren, zu der ein Ereignis passiert (unter Verwendung des IEEE-1588-Takts, der mit den Takten an jedem anderen Instrument in dem System synchronisiert ist). Zu dieser Zeit kann eine benutzerdefinierbare Ereignismeldung zu anderen Instrumenten auf dem Netzwerk gesendet werden oder eine andere interne Funktion kann ausgeführt werden, oder beides.
  • Als ein weiteres Beispiel kann das oben erwähnte synthetische System eines vernetzten Aufwärtswandlers und eines Digitalisierers deren Operationen koordiniert haben, unter Verwendung einer Kombination von einem zeitbasierten Modell und einem ereignisbasierten Modell, wie folgt:
    • 1. Der Hostcomputer definiert eine Ereignismeldung, die verwendet wird, um eine Messung zu starten. Diese neue Ereignismeldung wird die „Start"-Meldung genannt.
    • 2. Der Aufwärtswandler ist programmiert, um zu einer neuen Frequenz zu schalten, immer wenn er eine „Start"-Ereignismeldung empfängt. Genauer gesagt kann die „Start"-Meldung einen Zeitstempel enthalten und der Aufwärtswandler wird programmiert, um zu einer neuen Frequenz zu schalten, zu einer bestimmten Zeit danach. Dies macht Netzwerklatenzzeiten aus und stellt sicher, dass der Aufwärtswandler und der Digitalisierer von der selben Zeitbasis aus arbeiten.
    • 3. Es ist bekannt, dass das Ausgangssignal des Aufwärtswandlers nach 100 Mikrosekunden (μsec) einschwingt. Der Digitalisierer ist programmiert, um das Durchführen einer Messung zu beginnen, 100 μsec nachdem er eine „Start"-Ereignismeldung empfängt. Genauer gesagt kann der Digitalisierer den Zeitstempel aus der „Start"-Meldung verwenden, um eine Messung durchzuführen, 100 μsec nachdem der Aufwärtswandler schaltet.
    • 4. Der Hostcomputer führt ein Rundsenden einer „Start"-Ereignismeldung durch.
  • Eine spezifische Implementierung eines Ereignisverwalters ist nachfolgend detaillierter beschrieben, aber Ausführungsbeispiele sollen nicht auf diese spezifische Implementierung beschränkt sein.
  • Bei dieser darstellenden Implementierung ist der Ereignisverwalter auf viele Weisen analog zu einer Netzwerkdienst-Hintergrundroutine, wie z. B. einem FTP-Server oder einem Web-Server – er wartet auf Eingaben und handelt gemäß denselben. Bei einer solchen Implementierung ist der Ereignisverwalter ein Nur-Hören-Netzwerkserver, wenn Eingaben gehandhabt werden, aber seine Implementierung unterscheidet sich für Ausgabeereignisse. Diese darstellende Implementierung des Ereignisverwalters kann als eine Sammlung von Teilprozessen betrachtet werden, obwohl nicht angenommen werden sollte, dass der Ereignisverwalter tatsächlich unter Verwendung eines Teilprozessmodells implementiert ist (dies hängt von dem Betriebssystem ab). Die darstellende Implementierung kann als eine Sammlung von Teilprozessen modelliert sein, die alle auf eine Art von Eingabe warten. Jeder Teilprozess geht in den Schlafzustand, bis sein Eingabepuffer Daten verfügbar hat.
  • Eingabeereignisse kommen auf dem Kommunikationsnetzwerk an. Der Ereignisverwalter wartet einfach, dass eine Ereignismeldung ankommt, genau auf die Weise, auf die es ein anderer Netzwerkserver tun würde. Wenn eine Ereignismeldung ankommt, wacht der Ereignisverwalter auf und untersucht das Datenpaket. Wenn das Datenpaket eine Ereignis-ID enthält (nachfolgend weiter beschrieben), für die das Synchronisationsmodul programmiert wurde, um auf dieselbe zu antwor ten, ruft der Ereignisverwalter die entsprechende Rückrufroutine.
  • Ausgabeereignisse werden intern erzeugt. Häufig sind Ausgabeereignisse (z. B. Zeitbomben) das Ergebnis von Hardwareinterrupten. In diesem Fall ist eine Interrupt-Dienstroutine (ISR; ISR = interrupt service routine) zur Verwendung auf dem Instrument installiert. Die ISR ist verantwortlich für das Erfassen eines Zeitstempels für das Ereignis, das Speichern der Daten und das Aufwecken des Ereignisverwalters, der dann die entsprechende Rückrufroutine ausführt. Die ISR ist nicht dieselbe wie die Rückrufroutine.
  • Andere Ereignisse können unterschiedlich gehandhabt werden, abhängig von der Hardware/Software-Architektur des Instruments. Der Ereignisverwalter erlaubt, dass eine beliebige Rückrufroutine zu der Zeit eines Ereignisses ausgeführt wird, und dass die Rückrufroutine das Ereignis intern handhaben kann.
  • Bei dieser Beispielimplementierung basiert der Ereignisverwalter auf Sammelsendemeldungen. Das Sammelsenden wird üblicherweise über das UDP-Protokoll implementiert, das nicht als ein Hochzuverlässigkeitsdienst entworfen ist. Pakete können (und tun dies auch) verloren gehen. Es ist wünschenswert, dass der Ereignisverwalter die Fähigkeit aufweist, verlorene Pakete zu erfassen; aber da Ereignismeldungen bei den meisten Messinstrumenten zeitkritisch sind, ist es häufig gleichermaßen wünschenswert, den Mehraufwand zu vermeiden, der Handshake-Protokollen, wie z. B. dem TCP, eigen ist.
  • Die Zuverlässigkeit des Ereignisverwalters kann durch die Verwendung von einer oder mehreren der nachfolgenden Techniken verbessert werden:
    • 1. Sorgfältige Auswahl von Schaltern. Schalter sollten ausgewählt werden, die einen hohen Pegel an Speicherungs- und Weiterleitungs-Fähigkeit aufweisen, um einen Paketverlust zu minimieren, und die eine QoS-Funktionalität implementieren, so dass UDP-Paketen eine hohe Priorität gegeben werden kann.
    • 2. Redundantes Rundsenden von Ereignismeldungen. Ereignismeldungen können mehrere Male rundgesendet werden, um sicherzustellen, dass sie empfangen werden; die Empfangsmodule können konfiguriert sein, um mehrere Empfangsereignisse der selben Meldung zu ignorieren. Beispieltechniken, die ein redundantes Rundsenden von UDP-Paketen zum Verbessern der Zuverlässigkeit verwenden, sind weiter beschrieben in der gleichzeitig eingereichten und gemeinsam zugewiesenen deutschen Patentanmeldung Anwaltsaktenzeichen Nr. AG050620PDE mit dem Titel „SYSTEM UND VERFAHREN ZUR STABILEN KOMMUNIKATION ÜBER EIN UNZUVERLÄSSIGES PROTOKOLL", deren Offenbarung hierin durch Bezugnahme aufgenommen ist.
    • 3. Eine benutzerspezifizierte Auszeit für Ereignismeldungen. Wenn sich ein Synchronisationsmodul an einem Ereignis „beteiligt", wird eine maximale Zeitverzögerung für dieses Ereignis spezifiziert. Wenn eine Ereignismeldung ankommt, wird der Zeitstempel, der in der Ereignismeldung enthalten ist, mit der aktuellen Zeit verglichen. Wenn die Zeitdifferenz größer ist als das gegebene Maximum, dann tritt ein Fehlerzustand auf. Fehler können auf dem Kommunikationsnetzwerk rundgesendet werden oder zu dem Steuerungscomputer über eine TCP-Verbindung gesendet werden, als Beispiele.
  • Es gibt verschiedene Datentypen, die bei diesem darstellenden Beispiel eines Ereignisverwalters verwendet werden. Ein erster Datentyp ist Time (Zeit). Der Ereignisverwalter weist zwei unterschiedliche zeitbasierte Datentypen auf.
  • Einen für die absolute Zeit (TimeStamp = Zeitstempel), und einen anderen für Zeitintervalle (TimeInterval).
  • Ein anderer Datentyp ist Function ID (Funktions-ID) („FID"). Der FID ist ein Wert (z. B. eine 16-Bit-Ganzzahl), der eine interne Funktionalität eines Instruments darstellt. Er kann als eine instrumentspezifische Zahl implementiert sein, die verwendet wird, um verschiedene Funktionen zu identifizieren, die intrinsisch für das Instrument sind.
  • Instrumentfunktionen sind klassifiziert als „Eingaben" oder „Ausgaben". Bei dieser Nomenklatur ist eine „Ausgabe"-Funktion etwas, das intern auf dem Instrument passiert und dadurch verursacht, dass eine Ereignismeldung zu anderen Instrumenten gesendet wird. Eine „Eingabe"-Funktion ist eine solche, die das Instrument ansprechend darauf ausführen kann, dass eine Ereignismeldung von anderswo empfangen wird. Eine Zeitbombe ist eine spezielle Version einer Ausgabefunktion, für die spezifische API-Operationen existieren (z. B. zum Einstellen der Detonationszeit). Diese Funktionen entsprechen eng den Definitionen von „Eingabe-Ereignissen" und „Ausgabe-Ereignissen". Genauer gesagt ist ein „Eingabe-Ereignis" ein Ereignis, das zu der Ausführung einer „Eingabe-Funktion" führen würde.
  • Bei dieser Beispielimplementierung weist jedes Instrument eine Tabelle aus FID-Werten und ihre Beschreibungen auf, wie bei dem Beispiel, das in Tabelle 1 unten bereitgestellt wird:
  • Figure 00310001
    Tabelle 1
  • Es sollte darauf hingewiesen werden, dass einige dieser Funktionen auch einen entsprechenden Hardware-Auslöser haben können (entweder einen Auslöser-Eingang oder einen Auslöser-Ausgang).
  • Ein Benutzer kann programmatisch die Function-ID-Tabelle für ein gegebenes Instrument erweitern. Wenn ein Instrument programmiert werden muss, um auf ein externes Ereignis zu antworten, kann z. B. eine neue interne Funktion zu der Tabelle hinzugefügt werden.
  • Ein anderer Datentyp ist Event ID (Ereignis-ID) („EID"). Der EID ist ein benutzerdefinierter Wert (z. B. eine 16-Bit-Ganzzahl), der in einer rundgesendeten Ereignismeldung umfasst ist, um ein Ereignis zu identifizieren. Bei der Eingabe einer Ereignismeldung liest ein Instrument den EID, um zu bestimmen, ob es auf denselben antworten sollte oder nicht (z. B. zum Bestimmen, ob das identifizierte Ereignis ein solches ist, für das das Instrument konfiguriert/programmiert wurde, um eine Antwortaktion zu unternehmen). Bei der Ausgabe fügt das Instrument den EID zu dem Ereignismeldungspaket hinzu, so dass andere Instrumente die Quelle des Ereignisses identifizieren können.
  • Im Allgemeinen ermöglicht dies dem Benutzer, EID-Werte zu definieren, die mit FID-Werten verwendet werden. Zum Beispiel kann ein Instrument ein „Zeitbomben"-Ereignis erfahren, und der FID für dieses Ereignis ist „3" (und ist in das Instrument hart-codiert). Aber wenn eine Ereignismeldung als Folge dieses Ereignisses rundgesendet wird, ist der EID-Wert benutzerdefinierbar und muss nicht gleich dem FID sein.
  • Jedes individuelle Instrument kann voreingestellte EIDs für die meisten der FIDs vordefinieren. Aber der Systemintegrator/Endbenutzer kann die EID-Werte für alle FIDs nach Wunsch einstellen/ändern.
  • Der Benutzer kann z. B. EIDs spezifizieren, die für jedes Instrument in einem Testsystem eindeutig sind. Ansonsten können Probleme angetroffen werden, immer wenn ein Testsystem mehrere identische Instrumente umfasst. Für ein gegebenes Testsystem kann der Benutzer ferner eindeutige EIDs für die Ereignisse jedes Instruments spezifizieren.
  • Eine Function ID to Event ID map (Funktions-ID zu Event-ID-Abbildung) wird bei dieser Beispielimplementierung vorgelegt.
  • Das heißt, das Ereignisverwalter-Teilsystem bei jedem Instrument behält eine FID-zu-EID-Abbildung bei. Diese kann z. B. als eine Tabelle implementiert sein. Diese Tabelle behält die Abbildung zwischen EIDs und FIDs bei und umfasst ferner andere Daten, wie z. B:
    • (a) Ein Flag zum Sperren/Freigeben jeder Funktion.
    • (b) Die (Adresse von der) Rückruf-Funktion, die für das Ereignis verwendet wird.
    • (c) Informationen darüber, ob das fragliche Ereignis eine Eingabe oder eine Ausgabe ist. Während Zeitbomben Ausgabeereignisse sind, können sie in der Tabelle speziell mit einem Flag versehen sein, da sie spezifische API-Funktionen aufweisen, die ihnen zugeordnet sind.
    • (d) Einen Auszeit-Wert. Dieser wird für Eingabeereignisse verwendet und stellt die maximale Verzögerung dar, die toleriert werden kann, bevor eine Ereignismeldung empfangen wird.
  • Ein Beispiel einer solchen Tabelle für ein Instrument ist in Tabelle 2 unten bereitgestellt.
  • Figure 00330001
    Tabelle 2
  • Ein gegebener FID in der Tabelle stellt entweder eine Eingabe oder eine Ausgabe dar, aber nicht beides. Eine Zeitbombe ist ein spezieller Typ einer Ausgabe-Funktion. Tabelle 2 liefert ein Beispiel von Informationen, die zu den programmierten Ereignis-Informationen 102B der Quelle 12 gespeichert werden können. Die programmierten Ereignis-Informationen 102B und 102C der Steuerung 11 und des Empfängers 13 können auf ähnliche Weise angeordnet sein.
  • Die Freigabe-/Sperren-Einstellung aus Tabelle 2 reduziert einen unnötigen Verkehr über das Kommunikationsnetzwerk für Ausgabe-Ereignisse und wird verwendet, um relevante Ereignismeldungen für Eingabe-Ereignisse zu identifizieren. Standardmäßig kann das individuelle Instrument den Zustand des Freigeben/Sperren-Flag für alle Funktionen einstellen (die meisten werden gesperrt), und Standard-EIDs für jede Funktion einstellen. Es ist möglich, mehrere EIDs für einen gegebenen FID zu spezifizieren (und freizugeben). Dies gibt den Ereignisverwalter frei, um dieselbe Funktion auszuführen, wenn einer der EIDs empfangen wird.
  • Ein anderer Datentyp ist Event Message Data (Ereignismeldungsdaten). Gemäß dieser darstellenden Implementierung sind Ereignismeldungen von einem einfachen Datenformat und umfassen die nachfolgenden Informationen:
    • 1. Ereignis-ID
    • 2. Zeitstempel
    • 3. Anzahl von Bytes, die folgen
    • 4. Event-spezifische Daten
  • Ereignismeldungen werden unter Verwendung des SendEvent()-Rufs (Ereignissenderuf) gesendet. Üblicherweise wird diese Routine von innerhalb der Benutzer-Rückrufroutinen gerufen. Die Daten, die mit dem Ereignis gesendet werden, sind vorzugsweise minimal, um Netzwerklatenzzeitprobleme zu vermeiden/minimieren.
  • Verschiedene API-Funktionen sind bei dieser darstellenden Implementierung vorgesehen. Eine API-Funktion ist Reset() (Zurücksetzen). Diese Funktion setzt den Ereignisverwalter auf seinen voreingestellten (Fabrik-) Zustand zurück. Alle Funktionen werden gesperrt. Anstehende Zeitbomben und Ereignismeldungen werden abgebrochen. Benutzerdefinierte Ereignisse werden gelöscht.
  • Eine andere API-Funktion ist GetCurrentTime() (aktuelle Zeit erhalten). Diese Funktion bringt den aktuellen Wert des IEEE-1588-Takts zurück.
  • Eine andere API-Funktion ist CreateInputFn(FID) (Eingabefunktion erzeugen (FID)). Diese Funktion erzeugt eine neue Eingabe-Funktion mit dem gegebenen FID. Die Funktion wird ohne EIDs oder Rückrufe erzeugt und ist als eine Eingabe-Funktion markiert (nicht als eine Ausgabe-Funktion oder eine Zeitbombe). Sie gibt einen Fehler zurück und tut nichts, wenn der gegebene FID bereits verwendet wird, oder wenn nicht genug Speicher vorliegt, um die Funktionstabelle zu erweitern.
  • Eine andere API-Funktion ist DestroyInputFn(FID) (Eingabefunktion zerstören). Diese Funktion beseitigt die gegebene Funktion aus der Funktionstabelle. Sie sendet einen Fehler zurück und tut nichts, wenn der gegebene FID nicht existiert.
  • Eine andere API-Funktion, die vorgesehen ist, ist SetCall-BackFn(FID, CallBackFn, CancelCallBackFn, ErrorCallBackFn, PtrToVendorData) (Rückruffunktion einstellen (FID, Rückruffunktion, Rückruffunktion löschen, Fehler-Rückruffunktion, Zeiger auf Verkäuferdaten)). Diese Funktion stellt die Rückruffunktion für einen FID-Wert ein. Die „CallBackFn" (Rückruffunktion) wird gerufen, wenn ein Ereignis auftritt. Für Ausgabe-Ereignisse formatiert die Rückruffunktion üblicherweise eine Ereignismeldung und führt ein Rundsenden derselben auf dem Kommunikationsnetzwerk durch, obwohl der Ereignisverwalter die Funktionalität des Rückrufs nicht einschränkt. Für Eingabe-Ereignisse wird die Rückruffunkti on gerufen, wenn eine Ereignismeldung empfangen wird, die auf die gegebene Funktion abbildet.
  • Die „CancelCallBackFn" wird gerufen, immer wenn die Funktion gesperrt wird. Wenn die Funktion bereits gesperrt ist, wird dieser Rückruf nicht ausgeführt. Die „ErrorCallBackFn" (Fehler-Rückruf-Funktion) wird für Warnungen oder Fehler gerufen. Wenn z. B. eine Zeiteinstellung abläuft, kann dies erzwingen, dass einige Zeitbomben ignoriert werden und eine Warnung/Fehler wird verursacht. Die Typen der Fehler, die verursachen, dass diese Routine gerufen wird, sind im Allgemeinen instrumentspezifisch. Die SetCallBackFN (Rückruf-Einstellen-Funktion) tut nichts und sendet einen Fehler zurück, wenn ein Benutzer versucht, Rückrufe zu einem FID zuzuordnen, der nicht existiert.
  • Bei dieser Beispielimplementierung werden die nachfolgenden Parameter zu Rückruf-Funktionen geleitet:
    Funktion-ID
    Ereignis-ID
    Zeitstempel
    Verkäuferspezifische Daten
  • Um unnötige Funktionsrufe zu vermeiden, können beliebige der Rückruffunktionen Null sein.
  • Eine andere API-Funktion, die bereitgestellt wird, ist SetTimeout(FID,MaxYTimeDelay) (Auszeit einstellen(FID,MaxYZeitverzögerung)). Diese Funktion stellt die maximale Zeitverzögerung ein, die toleriert werden kann, bevor eine Ereignismeldung empfangen wird. Wenn ein empfangenes Ereignis um mehr als MaxTimeDelay (maximale Zeitverzögerung) verzögert wurde, dann tritt ein Fehlerzustand auf. Diese Funktion tut nichts und sendet einen Fehler zurück, wenn die gegebene Funktion keine Eingabe-Funktion ist.
  • MapFIDtoEID(FID,EID) ist eine andere API-Funktion, die bereitgestellt wird. Diese Funktion bildet einen gegebenen FID auf einen EID ab. Diese Funktion tut nichts und sendet einen Fehler zurück, wenn ein Benutzer versucht hat, von einer FID abzubilden, die nicht existiert.
  • UnMapFIDtoEID(FID,ID) ist eine API-Funktion, die eine Abbildung von einer gegebenen FID von einer EID aufhebt. Dies bringt die Abbildung in den voreingestellten Zustand zurück und sperrt ferner das Ereignis (siehe EnableEvent unten). Diese Funktionalität ist ähnlich zu dem EnableEvent-Ruf (unten), wird aber in Fällen verwendet, in denen mehrere EIDs in einen einzelnen FID abgebildet werden und nur die Abbildung von einem der EIDs aufgehoben werden soll. Diese Funktion tut nichts und sendet einen Fehler zurück, wenn das gegebene FID/EID-Paar nicht gefunden werden kann.
  • EnableEvent(FID,EID,true/false) (Ereignis freigeben (FID,EID,wahr/falsch) ist eine API-Funktion, die ein Ereignis unter Verwendung von FID oder EID oder beidem freigibt oder sperrt. Wenn die Funktion eine Eingabe ist, wird sie sich für alle Auftritte derselben beteiligen/die Beteiligung aufheben; und wenn die Funktion eine Ausgabe ist, wird sie alle Auftritte der Ausgabe freigeben/sperren. Wenn eine Null entweder für FID oder EID spezifiziert ist, wird der Parameter ignoriert und der andere Parameter (vermutlich ungleich Null) wird verwendet.
  • Wenn der gegebene FID Bezug auf eine Zeitbombe nimmt, soll die Funktion durch diese Funktion freigegeben und durch eine Funktion CreateTimeBomb() (Zeitbombe erzeugen) (siehe unten) initialisiert werden. Diese Funktion EnableEvent (Ereignis freigeben) kann verwendet werden, um eine Zeitbombe zu sperren, wobei sie in diesem Fall dasselbe tut wie der Ruf CancelTimeBomb() (Zeitbombe abbrechen). Diese EnableEvent-Funktion tut nichts und sendet einen Fehler zurück, wenn das FID/EID-Paar nicht gefunden werden kann.
  • SendEvent(EID, TimeStamp, Data, Bytes) (Ereignis senden (EID, Zeitstempel, Daten, Bytes) ist eine andere API-Funktion, die bereitgestellt wird. Diese Funktion führt ein Rundsenden einer Ereignismeldung aus. Sie soll von innerhalb der Rückrufroutinen gerufen werden und sollte nicht gerufen werden, wenn die Funktion gesperrt ist, obwohl dies keinen Fehler verursacht.
  • CreateTimeBomb(FID, TimeStamp, RepeatCount, TimeInterval) (Zeitbombe erzeugen (FID, Zeitstempel, Wiederholungsanzahl, Zeitintervall) ist eine andere API-Funktion, die vorgesehen ist. Diese Funktion stellt eine wiederholte Zeitbombe ein, die von dem gegebenen Zeitstempel startet, sich dann für RepeatCount-1 Male unter Verwendung des gegebenen Zeitintervalls wiederholt (so dass die Gesamtanzahl von Detonationen RepeatCount (Wiederholanzahl) ist). RepeatCount kann auf –1 für einen unendlichen Schleifendurchlauf eingestellt werden. Jedes Mal, wenn die Zeitbombe abläuft, wird Call-BackFn für eine Ausführung gerufen.
  • CreateTimeBomb(FID, TimeStamp, Frequency) (Zeitbombe erzeugen(FID, Zeitstempel, Frequenz) ist eine andere Funktion, die eine spezielle Version der obigen Funktion ist. Diese Funktion erzeugt eine wiederholte Zeitbombe mit repeat count = –1. Das Zeitintervall wird aus dem Frequenzparameter berechnet.
  • Eine andere API-Funktion, die vorgesehen ist, ist CancelTimeBomb(FID) (Zeitbombe abbrechen (FID)). Diese Funktion versucht, eine Zeitbombe abzubrechen. Es gibt keine Garantie, dass die Zeitbombe abgebrochen wird, bevor sie abfeuert. In einigen Fällen kann CallBackFn dies mit internen Flags handhaben. Diese Funktion CancelTimeBomb tut dasselbe wie EnableEvent() (Ereignis freigeben), wenn EnableEvent() verwendet wird, um eine Zeitbombenfunktion zu sperren. Die CancelTimeBomb-Funktion sendet einen Fehler zurück und tut nichts, wenn der gegebene FID keine eingestellte Zeitbombe aufweist, oder wenn der FID überhaupt keine Zeitbombe ist.
  • GetFunctionMap() (Funktionsabbildung erhalten) ist eine Funktion, die die Informationen zurücksendet, die in der FID-zu-EID-Abbildung (oben definiert) enthalten sind. Diese Funktion kann z. B. zu Fehlerbeseitigungszwecken verwendet werden.
  • Der Ereignisverwalter umfasst eine Netzwerkhintergrundroutine, die nach Befehlen auf dem Kommunikationsnetzwerk hört und entsprechende API-Rufe auf dem lokalen Prozessor des Instruments ausführt. Diese Funktionalität gibt einen (entfernten) Host-Computer frei, um ein Instrument für messspezifische Aufgaben zu programmieren. Der Steuerungscomputer kann z. B. ein Instrument programmieren, um eine Messung zu starten, wenn eine bestimmte Ereignismeldung empfangen wird. Um dies durchzuführen, sendet derselbe einen Programmierungsbefehl zu dem Instrument.
  • Wie oben beschrieben, hört der Ereignisverwalter auch nach Rundsende-Ereignismeldungen von anderen Instrumenten. Dies bedeutet, dass der Ereignisverwalter dieser Beispielimplementierung zwei Netzwerk-Höreinrichtungen umfasst: einen zum Hören nach Ereignismeldungen von anderen Instrumenten (der an einem Sammelsende-UDP-Tor hört), und einen zum Hören nach entfernten Programmierungsbefehlen (der an einem TCP-Tor hört).
  • Die Netzwerkhintergrundroutine hört einfach auf einem TCP-Tor nach Befehlen. Jeder Befehl kann durch zusätzliche Daten begleitet werden. Es wird darauf hingewiesen, dass die erlaubten Befehle den API-Funktionen entsprechen, die oben beschrieben sind.
  • Während eine darstellende Implementierung eines Ereignisverwalters detailliert oben beschrieben ist, sind Ausführungsbeispiele nicht auf diese Beispielimplementierung beschränkt. Statt dessen können verschiedene Merkmale und Implementierungsdetails, die oben vorgesehen sind, bei alternativen Ausführungsbeispielen geändert werden. Zum Beispiel kann bei bestimmten Ausführungsbeispielen das TCP zum Senden von Ereignismeldungen verwendet werden und nicht zum Rundsenden von Ereignismeldungen über UDP. Ferner können die verschiedenen Beispiel-API-Funktionen, die bei dem Beispielereignisverwalter vorgesehen sind, der oben beschrieben ist, sich ändern, alle oder einige solcher Funktionen können nicht vorgesehen sein und/oder zusätzliche Funktionen können bei alternativen Ereignisverwalter-Implementierungen vorgesehen sein.
  • Bezug nehmend auf 3 ist ein Operationsflussdiagramm zum Synchronisieren der Operation einer Mehrzahl von vernetzten Vorrichtungen gemäß einem Ausführungsbeispiel gezeigt. Bei Operationsblock 31 wird eine Ereignismeldung, die eine Identifikation eines Ereignisses und einen Zeitstempel umfasst, durch zumindest eine der Mehrzahl von vernetzten Vorrichtungen empfangen, wobei die Vorrichtungen synchronisierte Takte aufweisen. Wie oben beschrieben ist, wird bei bestimmten Ausführungsbeispielen die Ereignismeldung von einer Sendevorrichtung zu allen anderen Vorrichtungen auf dem Kommunikationsnetzwerk rundgesendet. Bei Block 32 bestimmt die zumindest eine Vorrichtung, die die Ereignismeldung empfangen hat, ob die empfangene Ereignismeldung ein Ereignis identifiziert, auf das hin die zumindest eine Empfangsvorrichtung handeln soll. Wie oben beschrieben ist, können bei bestimmten Ausführungsbeispielen die Vorrichtungen dynamisch programmiert sein, im Hinblick auf die Ereignisse, auf die sie eine Antwortaktion unternehmen sollen, sowie die spezifischen Antwortaktionen, die die Vorrichtung für ein gegebenes Ereignis unternehmen soll. Bei Block 33, wenn bestimmt wird, dass die empfangene Meldung ein Ereignis identifiziert, auf das hin die zumindest eine Empfangsvorrichtung handeln soll, dann handelt die zumindest eine Empfangsvorrichtung in Bezug auf das identifizierte Ereignis basierend auf dem Zeitstempel, der in der empfangenen Meldung umfasst ist. Somit kann die Aktion der Empfangsvorrichtung mit der Sendevorrichtung koordiniert werden, basierend auf ihren synchronisierten Takten.
  • Obwohl die vorliegende Erfindung und ihre Vorteile detailliert beschrieben wurden, sollte darauf hingewiesen werden, dass verschiedene Änderungen, Ersetzungen und Modifikationen hierin durchgeführt werden können, ohne von der Erfindung abzuweichen, wie sie durch die beiliegenden Ansprüche definiert wird. Ferner soll der Schutzbereich der vorliegenden Anmeldung nicht auf die bestimmten Ausführungsbeispiele des Prozesses, der Maschine, der Herstellung, der Zusammensetzung von Gegenständen, Einrichtungen, Verfahren und Schritten beschränkt sein, die in der Spezifikation beschrieben sind. Wie ein Durchschnittsfachmann aus der Offenbarung erkennen wird, können Prozesse, Maschinen, Herstellung, Zusammensetzung von Gegenständen, Einrichtungen, Verfahren oder Schritten, die bereits existieren oder später entwickelt werden, die im Wesentlichen dieselbe Funktion ausführen oder im Wesentlichen dasselbe Ergebnis erreichen wie die entsprechenden Ausführungsbeispiele, die hierin beschrieben sind, verwendet werden. Dementsprechend sollen die beiliegenden Ansprüche innerhalb ihres Schutzbereichs derartige Prozesse, Maschinen, Herstellungen, Zusammensetzungen von Gegenständen, Einrichtungen, Verfahren oder Schritten umfassen.

Claims (42)

  1. System, das folgende Merkmale aufweist: zumindest zwei Vorrichtungen (12, 13), die kommunikativ über ein Kommunikationsnetzwerk (14) gekoppelt sind, wobei die zumindest zwei Vorrichtungen eine Einrichtung zum Synchronisieren ihrer Takte (103B, 103C) umfassen; wobei die zumindest zwei Vorrichtungen (12, 13) eine Einrichtung zum Kommunizieren einer Meldung, die einen Zeitstempel umfasst und ein Ereignis identifiziert, über das Kommunikationsnetzwerk zu der anderen der zumindest zwei Vorrichtungen aufweisen; und wobei die zumindest zwei Vorrichtungen (12, 13) eine Einrichtung zum Empfangen der Meldung und zum Bestimmen einer Antwortaktion aufweisen, die ansprechend auf das identifizierte Ereignis unternommen werden soll, wobei eine bestimmte Aktion basierend auf dem Zeitstempel unternommen wird, der in der Meldung umfasst ist.
  2. System gemäß Anspruch 1, bei dem die Einrichtung zum Synchronisieren ihrer Takte folgendes Merkmal aufweist: eine Einrichtung zum Implementieren des IEEE-1588-Standards zum Synchronisieren der Takte.
  3. System gemäß Anspruch 1, bei dem die Einrichtung zum Synchronisieren ihrer Takte folgendes Merkmal aufweist: eine Einrichtung zum Implementieren eines Netzwerkzeitprotokolls (NTP) zum Synchronisieren ihrer Takte.
  4. System gemäß einem der Ansprüche 1 bis 3, bei dem die Einrichtung zum Synchronisieren ihrer Takte folgendes Merkmal aufweist: eine Einrichtung zum aktiven Synchronisieren der Takte durch die zumindest zwei Vorrichtungen (12, 13), die miteinander in Wechselwirkung sind.
  5. System gemäß einem der Ansprüche 1 bis 4, bei dem der Zeitstempel auf dem Takt der Vorrichtung basiert, die die Meldung sendet.
  6. System gemäß einem der Ansprüche 1 bis 5, bei dem die Einrichtung zum Kommunizieren der Meldung zu der anderen der zumindest zwei Vorrichtungen (12, 13) folgendes Merkmal aufweist: eine Einrichtung zum Rundsenden der Meldung über das Kommunikationsnetzwerk.
  7. System gemäß Anspruch 6, bei dem die Einrichtung zum Rundsenden die Meldung über ein Benutzerdatagrammprotokoll (UDP) sendet.
  8. System gemäß einem der Ansprüche 1 bis 7, bei dem die Einrichtung zum Empfangen der Meldung folgendes Merkmal aufweist: eine Einrichtung zum Empfangen einer rundgesendeten Meldung über das Kommunikationsnetzwerk (14).
  9. System gemäß einem der Ansprüche 1 bis 8, bei dem, wenn die Einrichtung zum Bestimmen einer Antwortaktion bestimmt, dass keine Aktion für das identifizierte Ereignis unternommen werden soll, dann die andere Vorrichtung keine Antwortaktion durchführt.
  10. System gemäß einem der Ansprüche 1 bis 9, bei dem die andere Vorrichtung im Hinblick auf die Antwortaktion programmierbar ist, die ansprechend auf das identifizierte Ereignis unternommen werden soll.
  11. System gemäß einem der Ansprüche 1 bis 10, bei dem die zumindest zwei Vorrichtungen Instrumente in einem Messsystem sind.
  12. System gemäß Anspruch 11, bei dem die zumindest zwei Vorrichtungen synthetische Instrumente sind.
  13. System gemäß einem der Ansprüche 1 bis 12, bei dem die andere Vorrichtung die bestimmte Antwortaktion an dem Zeitstempel unternimmt, der in der empfangenen Meldung umfasst ist.
  14. System gemäß einem der Ansprüche 1 bis 13, bei dem die andere Vorrichtung die bestimmte Antwortaktion zu einer definierten Zeit relativ zu dem Zeitstempel in der empfangenen Meldung unternimmt.
  15. System, das folgende Merkmale aufweist: zumindest zwei Vorrichtungen (12, 13), die kommunikativ über ein Kommunikationsnetz (14) gekoppelt sind, wobei die zumindest zwei Vorrichtungen synchronisierte Takte (103B, 103C) aufweisen; wobei die zumindest zwei Vorrichtungen jeweils einen Ereignisverwalter (101B, 101C) aufweisen, der wirksam ist, um Meldungen von der anderen der zumindest zwei Vorrichtungen zu empfangen, wobei die Meldungen Informationen umfassen, die ein Ereignis und einen Zeitstempel identifizieren; und wobei der Ereignisverwalter wirksam ist, um zu bestimmen, ob eine Aktion durch ihre entsprechende Vorrich tung ausgelöst werden soll, ansprechend auf ein identifiziertes Ereignis in einer empfangenen Meldung, wobei, wenn bestimmt wird, dass eine Aktion ausgelöst werden soll, eine solche Aktion basierend auf dem Zeitstempel ausgelöst wird, der in der empfangenen Meldung umfasst ist.
  16. System gemäß Anspruch 15, bei dem die zumindest zwei Vorrichtungen aktiv ihre Takte dadurch synchronisieren, dass sie miteinander in Wechselwirkung sind.
  17. System gemäß Anspruch 15 oder 16, bei dem die zumindest zwei Vorrichtungen ihre Takte gemäß dem IEEE-1588-Standard synchronisieren.
  18. System gemäß einem der Ansprüche 15 bis 17, bei dem der Zeitstempel auf dem Takt der Vorrichtung basiert, die die Meldung sendet.
  19. System gemäß einem der Ansprüche 15 bis 18, bei dem der Ereignisverwalter wirksam ist, um die Meldungen zu empfangen, die über das Kommunikationsnetzwerk (14) rundgesendet werden.
  20. System gemäß einem der Ansprüche 15 bis 19, bei dem der Ereignisverwalter wirksam ist, um eine Meldung über das Kommunikationsnetz (14) rundzusenden.
  21. System gemäß einem der Ansprüche 15 bis 20, bei dem die zumindest eine der Vorrichtungen (12, 13) im Hinblick auf die Aktion programmierbar ist, die ansprechend auf das identifizierte Ereignis ausgelöst werden soll.
  22. System gemäß einem der Ansprüche 15 bis 21, bei dem die Aktion an dem Zeitstempel ausgelöst wird, der in der empfangenen Meldung umfasst ist.
  23. System gemäß einem der Ansprüche 15 bis 22, bei dem die Aktion zu einer definierten Zeit relativ zu dem Zeitstempel in der empfangenen Meldung ausgelöst wird.
  24. System gemäß einem der Ansprüche 15 bis 23, bei dem die zumindest zwei Vorrichtungen (12, 13) Instrumente in einem Messsystem sind.
  25. System, das folgende Merkmale aufweist: eine Mehrzahl von Vorrichtungen, die kommunikativ über ein Kommunikationsnetzwerk (14) gekoppelt sind, wobei die zumindest zwei Vorrichtungen (12, 13) synchronisierte Takte aufweisen; wobei zumindest eine der Mehrzahl von Vorrichtungen (12, 13) eine Schnittstelle (104) zum Empfangen einer Eingabe aufweist, die die zumindest eine Vorrichtung programmiert, um eine definierte Aktion ansprechend auf ein spezifiziertes Ereignis zu unternehmen; wobei die zumindest eine der Mehrzahl von Vorrichtungen (12, 13) ferner einen Ereignisverwalter aufweist, der wirksam ist, um Meldungen von den anderen der Mehrzahl von Vorrichtungen zu empfangen, wobei die Meldungen Informationen umfassen, die ein Ereignis und einen Zeitstempel identifizieren; und wobei der Ereignisverwalter wirksam ist, um zu bestimmen, ob ein Ereignis, das durch eine empfangene Meldung identifiziert wird, ein Ereignis ist, für das die zumindest eine der Mehrzahl von Vorrichtungen (12, 13) programmiert ist, um eine entsprechende definierte Aktion zu unternehmen, und wenn das Ereignis, das durch eine empfangene Meldung identifiziert wird, ein Ereignis ist, für das die zumindest eine der Mehrzahl von Vorrichtungen programmiert ist, um eine entsprechende definierte Aktion zu unternehmen, der Ereignisverwal ter auslöst, dass die zumindest eine der Mehrzahl von Vorrichtungen die entsprechende definierte Aktion basierend auf dem Zeitstempel der empfangenen Meldung unternimmt.
  26. System gemäß Anspruch 25, bei dem die zumindest eine der Mehrzahl von Vorrichtungen die entsprechende definierte Aktion zu einer programmierten Zeit nach dem Zeitstempel der empfangenen Meldung unternimmt.
  27. System gemäß Anspruch 25 oder 26, bei dem der Ereignisverwalter wirksam ist, um die Meldungen zu empfangen, die über das Kommunikationsnetzwerk rundgesendet werden.
  28. Verfahren, das folgende Schritte aufweist: Empfangen (31), durch zumindest eine einer Mehrzahl von Vorrichtungen (12, 13), die kommunikativ mit einem Kommunikationsnetzwerk gekoppelt sind, einer Meldung, die eine Identifikation eines Ereignisses und einen Zeitstempel umfasst; Bestimmen (32), durch die zumindest eine Empfangsvorrichtung, ob die empfangene Meldung ein Ereignis identifiziert, auf das hin die zumindest eine Empfangsvorrichtung handeln soll; wenn bestimmt wird, dass die empfangene Meldung das Ereignis identifiziert, auf das hin die zumindest eine Empfangsvorrichtung handeln soll, dann Handeln der zumindest einen Empfangsvorrichtung auf das identifizierte Ereignis hin, basierend auf dem Zeitstempel, der in der empfangenen Meldung umfasst ist.
  29. Verfahren gemäß Anspruch 28, bei dem die zumindest eine Empfangsvorrichtung auf das identifizierte Ereig nis hin zu einer definierten Zeit nach dem Zeitstempel handelt.
  30. Verfahren gemäß Anspruch 28 oder 29, das ferner folgenden Schritt aufweist: Empfangen einer Programmierungsmeldung durch die zumindest eine Empfangsvorrichtung, die die Empfangsvorrichtung konfiguriert, um eine Aktion ansprechend auf ein Ereignis zu unternehmen.
  31. Verfahren gemäß einem der Ansprüche 28 bis 30, bei dem das Empfangen der Meldung folgenden Schritt aufweist: Empfangen der Meldung, die über das Kommunikationsnetzwerk (14) rundgesendet wird.
  32. Verfahren, das folgende Schritte aufweist: Senden einer Meldung über ein Kommunikationsnetzwerk (14) von einer ersten Vorrichtung zu zumindest einer anderen Vorrichtung, wobei die Meldung ein Ereignis identifiziert und einen Zeitstempel umfasst; Empfangen der Meldung durch die zumindest eine andere Vorrichtung; Bestimmen, durch die zumindest eine andere Vorrichtung, ob das Ereignis, das in der empfangenen Meldung identifiziert ist, durchführbar ist; und wenn durch die zumindest eine andere Vorrichtung bestimmt wird, dass das identifizierte Ereignis durchführbar ist, Unternehmen einer Aktion durch die zumindest eine andere Vorrichtung ansprechend auf das identifizierte Ereignis basierend auf dem Zeitstempel, der in der Meldung umfasst ist.
  33. Verfahren gemäß Anspruch 32, bei dem die Aktion, die durch die zumindest eine andere Vorrichtung unternommen wird, auf eine gewünschte Weise mit einer Aktion synchronisiert wird, die durch die erste Vorrichtung unternommen wird.
  34. Verfahren gemäß Anspruch 32 oder 33, bei dem das Senden ein Rundsenden aufweist.
  35. Verfahren gemäß einem der Ansprüche 32 bis 34, bei dem das Unternehmen einer Aktion durch die zumindest eine andere Vorrichtung ansprechend auf das identifizierte Ereignis folgenden Schritt aufweist: Unternehmen einer Messung.
  36. Verfahren gemäß einem der Ansprüche 32 bis 35, bei dem das Durchführen einer Aktion durch die zumindest eine andere Vorrichtung ansprechend auf das identifizierte Ereignis basierend auf dem Zeitstempel folgenden Schritt aufweist: Unternehmen der Aktion zu einer definierten Zeit relativ zu dem Zeitstempel.
  37. Verfahren gemäß einem der Ansprüche 32 bis 36, bei dem der Zeitstempel auf einem lokalen Takt der ersten Vorrichtung basiert, und bei dem lokale Takte der ersten Vorrichtung und der zumindest einen anderen Vorrichtung aktiv synchronisiert werden.
  38. Verfahren, das folgende Schritte aufweist: Programmieren einer Vorrichtung, um eine Aktion zu definieren, die die Vorrichtung ansprechend auf ein spezifiziertes Ereignis ausführen soll; Empfangen, durch die Vorrichtung, von Meldungen über ein Kommunikationsnetzwerk (14) von zumindest einer anderen Vorrichtung, mit der die Vorrichtung temporär synchronisiert ist, wobei die Meldungen jeweils ein Ereignis identifizieren und einen Zeitstempel umfassen; Bestimmen, durch die Vorrichtung, ob ein Ereignis, das durch eine empfangene Meldung identifiziert wird, das spezifizierte Ereignis ist; und wenn das Ereignis, das durch eine empfangene Meldung identifiziert wird, das spezifizierte Ereignis ist, dann Unternehmen der definierten Aktion durch die Vorrichtung basierend auf dem Zeitstempel der empfangenen Meldung.
  39. Verfahren gemäß Anspruch 38, bei dem die definierte Aktion das Unternehmen einer Messung ist.
  40. Verfahren gemäß Anspruch 38 oder 39, bei dem lokale Takte der Vorrichtung und der zumindest einen anderen Vorrichtung aktiv synchronisiert werden.
  41. Verfahren gemäß Anspruch 40, bei dem die lokalen Takte über ein Element synchronisiert werden, ausgewählt aus der Gruppe, bestehend aus: dem IEEE 1588 und dem Netzwerkzeitgebungsprotokoll (NTP).
  42. Verfahren gemäß einem der Ansprüche 38 bis 41, bei dem die Vorrichtung, die die definierte Aktion basierend auf dem Zeitstempel unternimmt, folgendes Merkmal aufweist: Unternehmen der definierten Aktion zu einer programmierten Zeit relativ zu dem Zeitstempel.
DE102005029440A 2004-09-13 2005-06-24 System und Verfahren zum Synchronisieren von Operationen einer Mehrzahl von Vorrichtungen über Meldungen über ein Kommunikationsnetzwerk Ceased DE102005029440A1 (de)

Applications Claiming Priority (2)

Application Number Priority Date Filing Date Title
US10/939,838 2004-09-13
US10/939,838 US8930579B2 (en) 2004-09-13 2004-09-13 System and method for synchronizing operations of a plurality of devices via messages over a communication network

Publications (1)

Publication Number Publication Date
DE102005029440A1 true DE102005029440A1 (de) 2006-03-30

Family

ID=35221290

Family Applications (1)

Application Number Title Priority Date Filing Date
DE102005029440A Ceased DE102005029440A1 (de) 2004-09-13 2005-06-24 System und Verfahren zum Synchronisieren von Operationen einer Mehrzahl von Vorrichtungen über Meldungen über ein Kommunikationsnetzwerk

Country Status (4)

Country Link
US (1) US8930579B2 (de)
JP (1) JP2006081192A (de)
DE (1) DE102005029440A1 (de)
GB (1) GB2418113A (de)

Families Citing this family (57)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
CN101080889B (zh) * 2004-12-16 2012-06-20 西门子企业通讯有限责任两合公司 按照ieee 1588标准的同步模块
US7573914B2 (en) * 2005-05-12 2009-08-11 Agilent Technologies, Inc. Systems and methods for synchronizing time across networks
US7174474B1 (en) * 2005-10-12 2007-02-06 Avago Technologies Ecbu Ip (Singapore) Pte. Ltd. Distributed autonomous control system for multi-axis motion control
US7840285B2 (en) * 2005-10-28 2010-11-23 Invensys Systems, Inc. Sequence of events recorder facility for an industrial process control environment
US7721133B2 (en) * 2006-04-27 2010-05-18 Hewlett-Packard Development Company, L.P. Systems and methods of synchronizing reference frequencies
US8078762B2 (en) 2006-06-14 2011-12-13 Continental Teves Ag & Co. Ohg Method for transmitting measured data, and sensor device
US8345561B2 (en) * 2006-08-22 2013-01-01 Rueters America Inc. Time monitor
US7770183B2 (en) * 2007-01-30 2010-08-03 Microsoft Corporation Indirect event stream correlation
US8219845B2 (en) * 2007-05-09 2012-07-10 Microsoft Corporation Timer service uses a single timer function to perform timing services for both relative and absolute timers
US20090063709A1 (en) * 2007-08-27 2009-03-05 Thomas Ambler Rice Method for Loading and Maintaining Executable Code Extensions in Instruments
US8838776B2 (en) * 2007-09-26 2014-09-16 Vega Grieshaber Kg Method for the automatic time synchronisation of devices in network-based systems
CN101399655B (zh) * 2007-09-27 2011-04-20 华为技术有限公司 穿通时钟设备同步端口的确定方法及装置
JP5239752B2 (ja) * 2008-10-31 2013-07-17 富士通株式会社 同期メッセージ発行システム、同期メッセージ発行方法および同期メッセージ発行プログラム
DE102009015920B4 (de) 2009-03-25 2014-11-20 Faro Technologies, Inc. Vorrichtung zum optischen Abtasten und Vermessen einer Umgebung
US9551575B2 (en) 2009-03-25 2017-01-24 Faro Technologies, Inc. Laser scanner having a multi-color light source and real-time color receiver
US9529083B2 (en) 2009-11-20 2016-12-27 Faro Technologies, Inc. Three-dimensional scanner with enhanced spectroscopic energy detector
DE102009057101A1 (de) 2009-11-20 2011-05-26 Faro Technologies, Inc., Lake Mary Vorrichtung zum optischen Abtasten und Vermessen einer Umgebung
US9210288B2 (en) 2009-11-20 2015-12-08 Faro Technologies, Inc. Three-dimensional scanner with dichroic beam splitters to capture a variety of signals
US9113023B2 (en) 2009-11-20 2015-08-18 Faro Technologies, Inc. Three-dimensional scanner with spectroscopic energy detector
DE102010008852B4 (de) * 2010-01-04 2011-09-01 Init Innovative Informatikanwendungen In Transport-, Verkehrs- Und Leitsystemen Gmbh Verfahren, Auswerterechner und Bordcomputer zur Beeinflussung einer Lichtsignalanlage
US8630314B2 (en) 2010-01-11 2014-01-14 Faro Technologies, Inc. Method and apparatus for synchronizing measurements taken by multiple metrology devices
US9607239B2 (en) 2010-01-20 2017-03-28 Faro Technologies, Inc. Articulated arm coordinate measurement machine having a 2D camera and method of obtaining 3D representations
US8677643B2 (en) 2010-01-20 2014-03-25 Faro Technologies, Inc. Coordinate measurement machines with removable accessories
US9879976B2 (en) 2010-01-20 2018-01-30 Faro Technologies, Inc. Articulated arm coordinate measurement machine that uses a 2D camera to determine 3D coordinates of smoothly continuous edge features
US8898919B2 (en) 2010-01-20 2014-12-02 Faro Technologies, Inc. Coordinate measurement machine with distance meter used to establish frame of reference
US9628775B2 (en) 2010-01-20 2017-04-18 Faro Technologies, Inc. Articulated arm coordinate measurement machine having a 2D camera and method of obtaining 3D representations
US8875409B2 (en) 2010-01-20 2014-11-04 Faro Technologies, Inc. Coordinate measurement machines with removable accessories
JP2013517498A (ja) 2010-01-20 2013-05-16 ファロ テクノロジーズ インコーポレーテッド 座標測定デバイスのためのカウンタバランス
US9163922B2 (en) 2010-01-20 2015-10-20 Faro Technologies, Inc. Coordinate measurement machine with distance meter and camera to determine dimensions within camera images
GB2489370B (en) 2010-01-20 2014-05-14 Faro Tech Inc Coordinate measuring machine having an illuminated probe end and method of operation
US8832954B2 (en) 2010-01-20 2014-09-16 Faro Technologies, Inc. Coordinate measurement machines with removable accessories
WO2011090895A1 (en) 2010-01-20 2011-07-28 Faro Technologies, Inc. Portable articulated arm coordinate measuring machine with multi-bus arm technology
US8615893B2 (en) 2010-01-20 2013-12-31 Faro Technologies, Inc. Portable articulated arm coordinate measuring machine having integrated software controls
DE102010020925B4 (de) 2010-05-10 2014-02-27 Faro Technologies, Inc. Verfahren zum optischen Abtasten und Vermessen einer Umgebung
US8489775B2 (en) * 2010-07-21 2013-07-16 Dell Products L.P. System-wide time synchronization across power management interfaces and sensor data
CN102986166B (zh) * 2010-07-23 2016-07-06 瑞典爱立信有限公司 记录控制平面事件
CN102347831B (zh) * 2010-07-26 2014-12-03 华为技术有限公司 时间消息处理方法、装置及系统
GB2501390B (en) 2010-09-08 2014-08-06 Faro Tech Inc A laser scanner or laser tracker having a projector
US9168654B2 (en) 2010-11-16 2015-10-27 Faro Technologies, Inc. Coordinate measuring machines with dual layer arm
CN101997671B (zh) * 2010-11-25 2014-12-10 中兴通讯股份有限公司 一种主从时钟设备的时钟同步方法及系统
CN102064933A (zh) * 2011-01-24 2011-05-18 华为技术有限公司 分组网络中时钟同步方法和装置、设备
JP5496320B2 (ja) * 2011-07-08 2014-05-21 グリー株式会社 メッセージ処理システム、メッセージ処理方法、およびプログラム
FR2983323B1 (fr) * 2011-11-28 2014-06-06 Schneider Electric Ind Sas Systeme de gestion de buffers d'evenements horodates
CN102412956B (zh) * 2011-11-29 2014-12-10 中兴通讯股份有限公司 协议单播方式同步的方法、设备和系统
DE102012100609A1 (de) 2012-01-25 2013-07-25 Faro Technologies, Inc. Vorrichtung zum optischen Abtasten und Vermessen einer Umgebung
US20150113174A1 (en) * 2012-05-03 2015-04-23 Telefonaktiebolaget L M Ericsson (Publ) Intelligent supervision for configuration of precision time protocol (ptp) entities
US9100330B1 (en) * 2012-07-13 2015-08-04 Emc Corporation Introduction of read delay or write delay in servers of a geographically distributed data processing system so that clients read up-to-date data
US8997362B2 (en) 2012-07-17 2015-04-07 Faro Technologies, Inc. Portable articulated arm coordinate measuring machine with optical communications bus
US9513107B2 (en) 2012-10-05 2016-12-06 Faro Technologies, Inc. Registration calculation between three-dimensional (3D) scans based on two-dimensional (2D) scan data from a 3D scanner
DE102012109481A1 (de) 2012-10-05 2014-04-10 Faro Technologies, Inc. Vorrichtung zum optischen Abtasten und Vermessen einer Umgebung
US10067231B2 (en) 2012-10-05 2018-09-04 Faro Technologies, Inc. Registration calculation of three-dimensional scanner data performed between scans based on measurements by two-dimensional scanner
US9342094B2 (en) * 2013-02-26 2016-05-17 Raytheon Company Multi-processor system and method for internal time synchronization and event scheduling of multiple processors
US9541947B2 (en) * 2013-08-07 2017-01-10 General Electric Company Time protocol based timing system for time-of-flight instruments
US9488964B2 (en) * 2014-06-27 2016-11-08 Apple Inc. Methods for maintaining accurate timing information on portable electronic devices
DE102015122844A1 (de) 2015-12-27 2017-06-29 Faro Technologies, Inc. 3D-Messvorrichtung mit Batteriepack
DE102016219663B4 (de) 2016-10-11 2018-08-02 Conti Temic Microelectronic Gmbh Verfahren zur Überwachung eines Netzwerks auf Anomalien
JP7251402B2 (ja) * 2019-08-20 2023-04-04 オムロン株式会社 制御システム、制御装置およびプログラム

Family Cites Families (85)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US5594280A (en) * 1987-10-08 1997-01-14 Anelva Corporation Method of forming a thin film and apparatus of forming a metal thin film utilizing temperature controlling means
US5214236A (en) * 1988-09-12 1993-05-25 Plessey South Africa Limited Timing of a multi-shot blast
US5293374A (en) * 1989-03-29 1994-03-08 Hewlett-Packard Company Measurement system control using real-time clocks and data buffers
US5887029A (en) * 1994-05-31 1999-03-23 Allen-Bradley Company, Llc Method of scheduling spatially separated control events with an industrial controller
US5566180A (en) * 1994-12-21 1996-10-15 Hewlett-Packard Company Method for recognizing events and synchronizing clocks
US5887143A (en) * 1995-10-26 1999-03-23 Hitachi, Ltd. Apparatus and method for synchronizing execution of programs in a distributed real-time computing system
US6826590B1 (en) * 1996-08-23 2004-11-30 Fieldbus Foundation Block-oriented control system on high speed ethernet
US6108782A (en) * 1996-12-13 2000-08-22 3Com Corporation Distributed remote monitoring (dRMON) for networks
US5987022A (en) * 1996-12-27 1999-11-16 Motorola, Inc. Method for transmitting multiple-protocol packetized data
US5878372A (en) * 1997-03-04 1999-03-02 Western Atlas International, Inc. Method for simultaneous inversion processing of well log data using a plurality of earth models
US6771594B1 (en) * 1997-03-31 2004-08-03 Intel Corporation Reliable/non-reliable transmission of voice using TCP/UDP based on network quality of service
US6161123A (en) * 1997-05-06 2000-12-12 Intermec Ip Corporation Providing reliable communication over an unreliable transport layer in a hand-held device using a persistent session
US6006254A (en) * 1997-08-29 1999-12-21 Mitsubishi Electric Information Technology Center America, Inc. System for the reliable, fast, low-latency communication of object state updates over a computer network by combining lossy and lossless communications
US6173207B1 (en) 1997-09-22 2001-01-09 Agilent Technologies, Inc. Real-time control system with non-deterministic communication
US7162510B2 (en) * 1998-03-16 2007-01-09 Schneider Automation Inc. Communication system for a control system over Ethernet and IP networks
US6865686B1 (en) * 1998-03-27 2005-03-08 Siemens Aktiengesellschaft Method for synchronizing a local time base on a central time base and device for implementing said method with preferred applications
US6615091B1 (en) * 1998-06-26 2003-09-02 Eveready Battery Company, Inc. Control system and method therefor
GB2387752B (en) 1998-07-22 2004-02-04 Agilent Technologies Inc Data acquisition and control system
US6611519B1 (en) * 1998-08-19 2003-08-26 Swxtch The Rules, Llc Layer one switching in a packet, cell, or frame-based network
US6278710B1 (en) * 1998-09-10 2001-08-21 Agilent Technologies, Inc. Enhancements to time synchronization in distributed systems
US6327274B1 (en) * 1998-09-15 2001-12-04 Nokia Telecommunications, Inc. Method for estimating relative skew between clocks in packet networks
FI107772B (fi) * 1998-12-16 2001-09-28 Nokia Networks Oy Menetelmä ja järjestelmä tiedonsiirron palvelunlaadun rajoittamiseksi
US6724729B1 (en) * 1998-12-30 2004-04-20 Finisar Corporation System analyzer and method for synchronizing a distributed system
JP2002535767A (ja) * 1999-01-07 2002-10-22 レメダン エイピーエス コンピュータ用制御装置、制御装置の使用方法、制御装置を有するコンピュータ、およびコンピュータ内のユニットの接続および分離方法
US6662217B1 (en) * 1999-01-19 2003-12-09 Microsoft Corporation Distributed and automated test administration system for administering automated tests on server computers over the internet
US20020026321A1 (en) * 1999-02-26 2002-02-28 Sadeg M. Faris Internet-based system and method for fairly and securely enabling timed-constrained competition using globally time-sychronized client subsystems and information servers having microsecond client-event resolution
US6611922B2 (en) * 1999-08-09 2003-08-26 Power Measurement, Ltd. Power system time synchronization device and method for sequence of event recording
US6236277B1 (en) * 1999-09-30 2001-05-22 Rockwell Technologies, Llc Low deviation synchronization clock
US6581110B1 (en) * 1999-12-07 2003-06-17 International Business Machines Corporation Method and system for reading and propagating authenticated time throughout a worldwide enterprise system
US6952727B1 (en) * 1999-12-07 2005-10-04 Schneider Automation Inc. Method for adapting a computer-to-computer communication protocol for use in an industrial control system
US6512990B1 (en) * 2000-01-05 2003-01-28 Agilent Technologies, Inc. Distributed trigger node
US6985499B2 (en) * 2000-04-20 2006-01-10 Symmetricom, Inc. Precise network time transfer
US7080160B2 (en) * 2000-04-27 2006-07-18 Qosmetrics, Inc. Method for creating accurate time-stamped frames sent between computers via a network
US6745232B1 (en) * 2000-08-23 2004-06-01 Rockwell Automation Technologies, Inc. Strobed synchronization providing diagnostics in a distributed system
JP3579826B2 (ja) * 2000-08-09 2004-10-20 インターナショナル・ビジネス・マシーンズ・コーポレーション データ処理システム、データロギングシステム、システムパフォーマンスの測定方法、および、記録媒体
US7224984B2 (en) * 2000-08-15 2007-05-29 University Of Maryland, College Park Method, system and computer program product for positioning and synchronizing wireless communications nodes
JP4314733B2 (ja) * 2000-08-22 2009-08-19 沖電気工業株式会社 通信接続装置およびデータ出力制御方法
JP4168582B2 (ja) * 2000-08-31 2008-10-22 沖電気工業株式会社 通信接続装置およびデータ出力制御方法
US7028204B2 (en) * 2000-09-06 2006-04-11 Schneider Automation Inc. Method and apparatus for ethernet prioritized device clock synchronization
US6839754B2 (en) * 2000-09-15 2005-01-04 Wm. Marsh Rice University Network tomography using closely-spaced unicast packets
US7054399B1 (en) * 2000-09-29 2006-05-30 Rockwell Automation Technologies, Inc. Low overhead synchronized activation of functional modules
US7035246B2 (en) * 2001-03-13 2006-04-25 Pulse-Link, Inc. Maintaining a global time reference among a group of networked devices
DE10113260B4 (de) * 2001-03-16 2005-10-20 Siemens Ag Synchrones, getaktetes Kommunikationssystem mit Relativuhr und Verfahren zum Aufbau eines solchen Systems
US6804793B2 (en) * 2001-03-16 2004-10-12 Hewlett-Packard Development Company, L.P. Manipulating an integrated circuit clock in response to early detection of an operation known to trigger an internal disturbance
DE10113261C2 (de) * 2001-03-16 2003-07-10 Siemens Ag Synchrones, getaktetes Kommunikationssystem mit dezentralen Ein-/Ausgabe-Baugruppen und Verfahren zur Einbindung dezentraler Ein-/Ausgabe-Baugruppen in ein solches System
US6983391B2 (en) 2001-05-09 2006-01-03 Agilent Technologies, Inc. Modular system with synchronized timing
US7219173B2 (en) * 2001-07-31 2007-05-15 Micronas Usa, Inc. System for video processing control and scheduling wherein commands are unaffected by signal interrupts and schedule commands are transmitted at precise time
US6915353B2 (en) * 2001-08-01 2005-07-05 Hewlett-Packard Development Company, L.P. Method and apparatus for avoiding unnecessary computer peripheral calibration activities
US6894953B2 (en) * 2001-09-12 2005-05-17 Lockheed Martin Corporation Circuit for measuring time of arrival of an asynchronous event
WO2003028258A1 (de) * 2001-09-26 2003-04-03 Siemens Aktiengesellschaft Verfahren zur synchronisation von knoten eines kommunikationssystems
US6996624B1 (en) * 2001-09-27 2006-02-07 Apple Computer, Inc. Reliable real-time transport protocol
US7054902B2 (en) * 2001-10-23 2006-05-30 Packeteer, Inc. Multicast delivery systems and methods
KR100431003B1 (ko) * 2001-10-31 2004-05-12 삼성전자주식회사 데이터 송수신 시스템 및 방법
US6498968B1 (en) * 2001-11-27 2002-12-24 Lockheed Martin Corporation Optimistic distributed simulation for a UAV flight control system
US7069325B1 (en) * 2001-12-21 2006-06-27 Cisco Technology, Inc. Method and apparatus for handling requests in a network
US7036013B2 (en) * 2002-01-31 2006-04-25 Brocade Communications Systems, Inc. Secure distributed time service in the fabric environment
US7133368B2 (en) * 2002-02-01 2006-11-07 Microsoft Corporation Peer-to-peer method of quality of service (QoS) probing and analysis and infrastructure employing same
US6741952B2 (en) * 2002-02-15 2004-05-25 Agilent Technologies, Inc. Instrument timing using synchronized clocks
GB2385499A (en) 2002-02-18 2003-08-20 Venation Ltd Network transport protocol
US7111195B2 (en) * 2002-02-25 2006-09-19 General Electric Company Method and system for external clock to obtain multiple synchronized redundant computers
US7114091B2 (en) * 2002-03-18 2006-09-26 National Instruments Corporation Synchronization of distributed systems
GB2386982A (en) 2002-03-28 2003-10-01 Sony Uk Ltd Data network with outputs delays to give constant time between input and output
US7254191B2 (en) * 2002-04-22 2007-08-07 Cognio, Inc. System and method for real-time spectrum analysis in a radio device
KR100431700B1 (ko) * 2002-08-16 2004-05-17 엘지전자 주식회사 에스지에스엔과 지지에스엔간의 시각 동기화 시스템 및 방법
US7313098B2 (en) * 2002-09-30 2007-12-25 Avaya Technology Corp. Communication system endpoint device with integrated call synthesis capability
US7079977B2 (en) * 2002-10-15 2006-07-18 Medtronic, Inc. Synchronization and calibration of clocks for a medical device and calibrated clock
US7106823B2 (en) * 2002-11-15 2006-09-12 Broadcom Corporation System and method for accelerated clock synchronization of remotely distributed electronic devices
US6983393B2 (en) * 2002-12-11 2006-01-03 National Instruments Corporation Deterministically handling asynchronous events in a time triggered system
US7058838B2 (en) * 2002-12-17 2006-06-06 Hewlett-Packard Development Company, L.P. System and method for synchronizing a plurality of processors in a multiprocessor computer platform employing a global clock counter
US7379480B2 (en) * 2003-01-16 2008-05-27 Rockwell Automation Technologies, Inc. Fast frequency adjustment method for synchronizing network clocks
US7478151B1 (en) * 2003-01-23 2009-01-13 Gomez, Inc. System and method for monitoring global network performance
US7804852B1 (en) * 2003-01-24 2010-09-28 Douglas Durham Systems and methods for definition and use of a common time base in multi-protocol environments
DE602004017423D1 (de) * 2003-02-20 2008-12-11 Zarlink Semiconductor Inc Synchronisation von takten über mehrerepaketnetzwerke hinweg
DE10309164A1 (de) * 2003-02-28 2004-09-09 Siemens Ag Scheduling von Echtzeitkommunikation in geschalteten Netzwerken
DE10333934A1 (de) * 2003-07-25 2005-02-17 Robert Bosch Gmbh Synchronisation von datenverarbeitenden Einheiten
US7340630B2 (en) * 2003-08-08 2008-03-04 Hewlett-Packard Development Company, L.P. Multiprocessor system with interactive synchronization of local clocks
DE112004002233B4 (de) * 2003-11-19 2018-07-12 Nimcat Networks Inc. Zeit- und Datensynchronisation zwischen Netzwerkeinrichtungen
US20050144309A1 (en) * 2003-12-16 2005-06-30 Intel Corporation, A Delaware Corporation Systems and methods for controlling congestion using a time-stamp
US7203858B2 (en) * 2003-12-19 2007-04-10 Intel Corporation Program clock synchronization in multimedia networks
US7457868B1 (en) * 2003-12-30 2008-11-25 Emc Corporation Methods and apparatus for measuring network performance
US7590151B2 (en) * 2004-02-09 2009-09-15 Semtech Corporation Method and apparatus for aligning time references when separated by an unreliable data packet network
US7315791B2 (en) * 2004-02-18 2008-01-01 National Instruments Corporation Application programming interface for synchronizing multiple instrumentation devices
US7701884B2 (en) * 2004-04-19 2010-04-20 Insors Integrated Communications Network communications bandwidth control
US7478349B2 (en) * 2004-08-13 2009-01-13 National Instruments Corporation Automatically synchronizing timed circuits on I/O Devices
US7643595B2 (en) * 2004-09-13 2010-01-05 Nortel Networks Limited Method and apparatus for synchronizing clock timing between network elements

Also Published As

Publication number Publication date
GB0518522D0 (en) 2005-10-19
US20060059270A1 (en) 2006-03-16
GB2418113A (en) 2006-03-15
JP2006081192A (ja) 2006-03-23
US8930579B2 (en) 2015-01-06

Similar Documents

Publication Publication Date Title
DE102005029440A1 (de) System und Verfahren zum Synchronisieren von Operationen einer Mehrzahl von Vorrichtungen über Meldungen über ein Kommunikationsnetzwerk
DE102005029439A1 (de) Zusatz-Modul zum Synchronisieren von Operationen einer Mehrzahl von Vorrichtungen
DE102005029422A1 (de) System und Verfahren zum Koordinieren der Aktionen einer Mehrzahl von Vorrichtungen über ein Planen der Aktionen basierend auf synchronisierten lokalen Takten
DE102018132290B4 (de) Fahrzeuginternes System, Gateway, Relais, nichttransitorisches computerlesbares Medium zum Speichern eines Programms, Informationsverarbeitungsverfahren, Informationsverarbeitungssystem und Fahrzeug
EP1368935B1 (de) Synchrones, getaktetes kommunikationssystem mit dezentralen ein-/ausgabe-baugruppen und verfahren zur einbindung dezentraler ein-/ausgabe-baugruppen in ein solches system
DE69533579T2 (de) Synchronisierung in einem Datenkommunikationsnetzwerk
DE102011111268B4 (de) Steuerungseinheit und Kommunikationssteuerungssystem
EP1659718B1 (de) Synchronisatonsverfahren und Steuerungssystem für die Synchronisation von Nebeneinheiten, sowie synchronisierbare Nebeneinheiten
EP1657619B1 (de) Verfahren zur Zeitsynchronisation in einem zyklisch arbeitenden Kommunikationssystem
DE102007037092A1 (de) Zeitsynchronisation für netzwerkbewusste Vorrichtungen
DE102006012466A1 (de) Systeme und Verfahren zum Synchronisieren einer Zeit über Netze hinweg
EP2795856B1 (de) Verfahren zur zeitrichtigen beobachtung von tt ethernet nachrichten
DE102008000562A1 (de) Kommunikationssystem umfassend einen Datenbus und mehrere daran angeschlossene Teilnehmerknoten sowie Verfahren zum Betreiben eines solchen Kommunikationssystems
DE102007045083A1 (de) Verstärkung einer IEEE-1588-Synchronisation unter Verwendung eines Außer-Band-Kommunikationspfades
DE112012006762T5 (de) Kommunikationsvorrichtung, Kommunikationssystem und synchrones Steuerverfahren
DE102007044470A1 (de) Mechanismus, um eine Verzögerung von Netzwerkelementen transparent für IEEE-1588-Protokolle zu machen
DE60316758T2 (de) System zur Synchronisierung von Befehlen, sowie ein Verfahren, ein Steuerungsgerät und ein Zielgerät für dasselbe System
EP3170285B1 (de) Verfahren zum bestimmen einer übertragungszeit eines telegramms in einem kommunikationsnetzwerk und entsprechende netzwerkkomponenten
DE10361178B4 (de) Datenalterungsüberwachungsvorrichtung für Sicherheitsnetzwerke
EP3814856B1 (de) Echtzeit-automatisierungseinrichtung mit einem echtzeit-datenbus
DE10131307A1 (de) Verfahren und Bussystem zum Synchronisieren eines Datenaustausches zwischen einer Datenquelle und einer Steuereinrichtung
WO2011117239A1 (de) Verfahren und vorrichtung zur verarbeitung von daten in einem netzwerk eines fahrzeugs
DE602004010403T2 (de) System zur prüfung eines funkgerätes
DE102019220495A1 (de) Verfahren zur Prüfung der Gültigkeit von Sensordaten eines Ethernet-Bordnetzes
EP2932634B1 (de) Zuweisen von zeitstempeln zu empfangenen datenpaketen

Legal Events

Date Code Title Description
OP8 Request for examination as to paragraph 44 patent law
8127 New person/name/address of the applicant

Owner name: AGILENT TECHNOLOGIES, INC. (N.D.GES.D. STAATES, US

8131 Rejection