DE102005029440A1 - A system and method for synchronizing operations of a plurality of devices via communications over a communications network - Google Patents

Abstract

A system and method synchronize operations of a plurality of devices via communications over a communications network. A plurality of devices are communicatively coupled via a communications network, and the devices have their local clocks synchronized to a high degree of precision by a technique such as a video recorder. IEEE 1588, to synchronize their local clocks. Event messages may be sent that include an identification of an event as well as a timestamp based on the sender's local clock. The receiver of an event message determines if it is configured to act upon the identified event and, if so, takes its action based on the timestamp included in the event message. In certain embodiments, the events must trigger that an action and / or the specific response actions to be performed for a given event are dynamically programmable for each device.

Description

reference on related applications

These Registration refers to concurrently submitted and shared Assigned German patent applications Attorney Docket AG050618PDE entitled "SYSTEM AND METHOD FOR COORDINATING THE ACTIONS OF A MULTIPLE OF DEVICES OVER PLANNING ACTIONS BASED ON SYNCHRONIZED LOCAL CYCLES ", Attorney Docket No. AG050620PDE entitled "SYSTEM AND METHOD FOR STABLE COMMUNICATION ON AN UNRESOLVED PROTOCOL "and attorney docket No. AG050619PDE entitled "ADDITIONAL MODULE FOR SYNCHRONIZING OPERATIONS OF A NUMBER OF DEVICES ", their disclosures are incorporated herein by reference.

description

The Synchronization of the operation of various components of a system is common he wishes. To the For example, for measuring systems that consist of several traditional all-in-one case instruments Complex measurements often require different instruments be controlled together to properly synchronize their respective operations. As examples it should be spectrum analyzers not be allowed to take measurements until signal sources settle are; Power meter measurements should not be taken until a sufficient number of Samples were averaged to ensure accuracy; and Frequency sweep sources should not be allowed on one switch new frequency until measurements at the current frequency Are completed. Thus, it becomes desirable to have the relative Synchronize operations of different instruments.

Become frequent Hardware trigger lines used to synchronize the various instruments in a system. Hardware trigger lines are particularly effective in measuring systems where precise synchronization is required, or where a measuring speed is important. If hardware trigger lines implemented, the instruments have a trigger output and a trigger input with a dedicated hardware line on (eg, wire), the trigger output an instrument with the trigger input another instrument connects.

To the For example, a spectrum analyzer typically includes a receiver and a digitizer in the same housing, the output signal from the receiver should be measured after a certain period of time Had settled. When implementing hardware trigger lines between the recipient and the digitizer the recipient a trigger output gate have that over a hardware line (eg, wire) to the trigger input port of the digitizer is coupled. The voltage on this hardware line goes to the Time high, to which the output signal from the receiver settled is, and the trigger input the digitizer unit detects this voltage transition too high and dissolves thus the beginning of the measurement. Thus, the hardware trigger line sure that the relative operations of the instruments at one desired Way synchronized.

The Hardware trigger line technology requires a physical wire between these two instruments runs, and the function of this wire is fixed and earmarked for use as a trigger. Further increased the inclusion of such hardware trigger lines the amount of wiring and leads thus often to wiring complexities and / or complications such. B. Problems with regard to Guide the wires and an increased Difficulty fixing problems. Further, when the Length of Hardware trigger line elevated (eg because the paired instruments are farther apart are arranged), increased Also, the latency of signals over such a hardware trigger line be communicated.

Another synchronization technique uses software to control the operations of the various instruments in a synchronized manner. Such software synchronization can be used in situations where hardware triggers are not available, such as: For example, if the instruments to be synchronized are too far apart to allow use of a hardware trigger line. In implementing software to control the synchronization of the operation of various instruments, the software may use predefined time delays, interrogating the instruments and / or software interrupts to coordinate the actions of the instruments. For example, after If a first instrument is instructed to take a first action, the software in an external controller may wait a specific amount of time before instructing another instrument to take a given action to be taken after completion of the first action. In some cases, the software in the external controller may query an instrument to determine when it has completed a given function so that the software can determine when it is appropriate to trigger the next action. In certain cases, the instruments may be implemented to send a signal to the external controller to generate a software interrupt in the controller, e.g. B. indicates that a given instrument has completed a particular operation.

When an example for using a software synchronization technique in synchronization of operations of the above receiver and digitizer, a control computer can send a message to the recipient Send the same instructing to change the frequency. It is known that requires a certain waiting time before the measurement of the signal having the changed frequency is triggered (to enable that change resonates at the frequency). So, after the receiver instructed was to change his frequency, the control computer waits (or "sleeps") for a predetermined period of time, such as z. B. 100 milliseconds. The control computer then assigns the digitizer on, performing to start a measurement.

It are also techniques for synchronizing the clocks of networked Devices known to a high degree of precision. For example is a Network Time Protocol (NTP) a protocol that is used to make computer clocks in one Network from computers to sync. Together with similar The NTP uses a coordinated universal time (UTC; UTC = Coordinated Universal Time) to set computer clock times to within to synchronize a millisecond and sometimes within one Fraction of a millisecond. As another example, the Institute of Electrical and Electronics Engineers Standards Association (IEEE-SA) approved a new standard to maintain synchronism between Clocking on a network, referred to as the IEEE 1588 "standard for a Precision Synchronization Protocol for Networked Measurement and Control Systems "(Standard for a Precision synchronization protocol for networked Measuring and control systems). In general, this standard defines IEEE 1588 messages that can be used to provide timing information between networked devices to synchronize their clocks to keep. The IEEE 1588 standard even allows for a higher degree in precision (eg down to within a microsecond) in clock synchronization as the one provided by the NTP.

While, however Techniques such. NTP and the standard IEEE 1588 techniques for Synchronizing the clocks of networked devices to one high degree of precision such that the networked devices, respectively have a local clock, have a common sense of time, These techniques do not address the synchronization of the operation of the devices. Instead, such techniques concentrate to keep synchronized clocks active between networked ones Devices. Thus, the active clock synchronization techniques leave it Open as the devices take effect their synchronized clocks use, if any, to synchronize their respective operations.

It The object of the present invention is a system and a method with improved characteristics.

These The object is achieved by a system according to claim 1, 15 and 25 and by a method according to claim 28, 32 and 38 solved.

The present invention is directed to a system and method that synchronizes operations of a plurality of devices via communications over a communications network. Thus, a plurality of devices are communicatively coupled via a communication network, and the local clocks of the devices are synchronized to a high degree of precision, using IEEE 1588, NTP or other technique for synchronizing their local clocks. Event messages may be sent that include an identification of an event and a timestamp based on the sender's local clock. The receiver of an event message may determine if it is configured / programmed to act upon the identified event, and if it is to act on the identified event, it may take its action based on the timestamp included in the event message , In certain embodiments, the events that are to trigger an action and / or the specific responsive actions to be taken for a given event are dyna can be programmed for each device. As further described herein, the event messages may be used to coordinate the operations of various devices with a high degree of temporal precision, since the actions taken on each device may be based on the timestamp included in the event message is.

To the Example shows a system according to at least an embodiment at least two devices communicatively over one Communication network are coupled, wherein the at least two devices comprise means for synchronizing their clocks. The device to synchronize their clocks synchronized according to different Embodiments provided herein the local clocks of the devices, eg. B. by exchanging messages between the devices. Such synchronized clocks can, for example according to the IEEE 1588 standard or the NTP standard to be implemented. The at least two devices also have means for communicating with the other one the at least two devices via the communication network on, on a message that includes a timestamp and an event identified. Furthermore, the at least two devices have one Device for receiving the message and for determining a Response action made in response to the identified event should be, taking a specific action based on the timestamp which is included in the message. Thus, operations of the devices coordinated based on their local synchronized clocks be through the use of event messages that over the Communication network are communicated.

at certain embodiments the event messages get over the communication network broadcast, z. B. using a UDP. Thus, the sender of the event message does not have to to deal with which other device (s) the message should not be sent, and may not even be aware which other devices are coupled to the communication network are. All devices on the communication network (eg LAN or a subnet of a WAN) can broadcast the broadcast event message and each device can determine if it is configured to take action, responsive to the identified Event. If a receiving device is not configured, an action for To do the identified event, it can be the most broadcast Ignore event message. Naturally can in other embodiments the event messages are sent in a non-broadcast manner, such as More colorful Using a TCP.

The Previous has quite extensive features and technical Advantages of the present invention carried out so that the detailed Description of the invention which follows, is better understood. additional Features and advantages of the invention will be described hereinafter, the subject of the claims form the invention. It should be noted that the design and specific embodiment herein readily as a basis for modification or design Other structures can be used for the same purposes to carry out the present invention. It should also be recognized that such equivalent designs are not of the invention differ as set forth in the accompanying claims. The new features, which are characteristic of the invention, both in terms of organization as to the procedure of the operation, are together with others Objectives and advantages from the description below better understandable, if it is considered in conjunction with the accompanying figures. It is, however, explicit noted that each of the figures for the purpose of illustration and the description is presented rather than a definition the limits of the present invention is intended.

preferred embodiments The present invention will be described below with reference to FIG the enclosed drawings closer explained. Show it:

1 an example system according to an embodiment for synchronizing operations of a plurality of networked devices;

2 a specific example of using a message-based technique in the system 1 for coordinating the operations of the networked devices; and

3 an operational flowchart for synchronizing the operation of a plurality of networked devices according to one embodiment.

As described above, measurement systems often require that the operation of various In instruments are synchronized (or coordinated) in a suitable manner to allow accurate measurements to be obtained. For example, a spectrum analyzer should be coordinated to perform its measurements after a signal source has had sufficient opportunity to settle at its output frequency.

The entire or a section of a measuring system can be made with "synthetic Instruments "be formed. Synthetic instruments are unable to take measurements themselves but instead there must be a collection of them work together to implement a measurement. On the other hand included conventional All-in-one housing instruments (herein referred to as "fully completed Instruments ") completely all Subsystems that are to perform a desired one Measurement needed. For example, a spectrum analyzer may be considered a fully completed Instrument, or such a spectrum analyzer can be formed by a collection of synthetic instruments be such. A receiver, Digitizer, etc., communicatively via a communication network are coupled. A complete completed system may need form an interface with another system, to something for To have fairs. For example, a fully terminated spectrum analyzer forms an interface with a source to measure the signal that delivered by the source. No matter if a majority of completely closed Instruments (eg spectrum analyzer, RF source etc.) or a plurality of synthetic instruments (or a combination of completely closed and synthetic instruments), it is often desirable that the relative operations of the various instruments to a particular one Be coordinated in order to allow accurate measurements.

Within the traditional, complete completed instruments can various subsystems Timing and synchronization functions via hardware trigger lines (hardware trigger line) and / or its underlying firmware to reach. Synthetic instruments, the functional parts of the fully completed Instruments are, must possibly be synchronized in a different way because z. B. such synthetic Instruments may be too far apart than that use of hardware trigger lines is practical, and / or the wiring complexities involved in implementing such hardware trigger lines are involved this solution undesirable do. Additionally are the requirements for synchronization of synthetic instruments often Stricter than for the Synchronization between separate fully contained instruments, due to the fact that every synthetic instrument (or "module") has a smaller size set of functionality contains.

reference taking again the above-mentioned example of a spectrum analyzer include modern, complete completed spectrum analyzers usually a receiver and a digitizer. The firmware of the spectrum analyzer controls the frequency sweep of the receiver as well as the digitizer and can easily use the digitizer with the receiver frequency synchronize to ensure that measurements are performed correctly. On the other hand, a synthetic instrument system might have a receiver and a digitizer, but not in the same instrument. A synchronization between these devices is therefore not contained in a single instrument. In this synthetic Instrument system is a synchronization of the digitizer with the receiver frequency desired to To ensure that the digitizer performs measurements at the time, too the receiver frequency has settled, and not earlier or later as that techniques are provided herein for synchronization the operations of a plurality of synthetic instruments and / or fully completed Instruments can be used.

Referring to 1 is an example system 10 according to an embodiment for synchronizing operations of a plurality of networked devices (or "instruments") 10 includes a controller 11 , a source 12 and a receiver 13 , all communicatively via a communication network 14 A local area network (LAN), the Internet or other wide area network (WAN), a public switched telephony network (PSTN), a wireless network Network, a combination of the preceding and / or another network that is already known or later developed, for communicating information from at least one device to at least one other device. While a source 12 and a receiver 13 In this example, it should be understood that embodiments for synchronizing operations described herein are not limited in their application to these exemplary instruments. The techniques described herein may be used to synchronize the operations of instruments that make up a measurement system. Such techniques may be used to synchronize the operations of synthetic instruments of a measurement system and / or fully contained instruments. Further, while the techniques a have particular applicability to measurement systems to synchronize the operations of various instruments to a high degree of precision used to make measurements, the techniques described herein can be similarly employed in other types of systems in which the synchronization of Operations of a plurality of networked devices is desired.

The control 11 , which may be a personal computer (PC) or other processor-based device, includes a central processing unit (CPU). 105A , Similarly, the source includes 12 a CPU 105B and the receiver 13 includes a CPU 105C , The bars of each element from control 11 , Source 12 and receiver 13 are synchronized in this example. In this specific example, the IEEE 1588 is used, with the controller 11 the IEEE 1588 clock 103A implemented, the source 12 the IEEE 1588 clock 103B implemented and the receiver 13 the IEEE 1588 clock 103C implemented. Of course, other techniques for actively synchronizing the local clocks, such as clocking. Using NTP, in other implementations. The local clocks are referred to as being "actively synchronized" because the devices interact with each other to keep their respective local clocks synchronized according to the particular synchronization technique used (eg, IEEE 1588 or NTP) Other Techniques (eg, passive techniques) may be used in alternative embodiments to synchronize the local clocks, using global positioning system (GPS) receivers, etc. Thus, the controller has 11 , the source 12 and the receiver 13 their local bars 103A . 103B and 103C synchronized to a high degree of precision so that they all share a common sense of time. As further described herein, the local clock of the controller must be 11 in certain embodiments may not be synchronized with the clocks of the other instruments in the measuring system, such as, for example, B. that of the source 12 and the recipient 13 ,

The control 11 , the source 12 and the receiver 13 each have an event manager running on them labeled as 101A . 101B respectively. 101C , In general, the event manager is software and / or hardware designed to allow the various instruments to communicate information about time-sensitive events. The operation of the event manager according to this exemplary embodiment will be further described below.

Before discussing the example system 10 out 2 it is helpful to briefly discuss some of the terminology used herein.

The term "event", when used alone, refers to something that happens within an instrument, such as in the source 12 or in the receiver 13 of the example system 10 , For example, an event could be generated when the input buffer of a digitizer fills or when an output signal has settled. Events are usually generated by the hardware of an instrument, although this is not a limitation. Software can also generate events.

Of the Expression "Event message" refers to a message sent on the communication network which is used to notify other instruments that an event has occurred. For certain supplied herein embodiments Event messages z. Using a user datagram protocol (UDP = User Datagram Protocol) to all instruments on one given communication network (eg on a given subnetwork) broadcast. In other embodiments the event messages get over a point-to-point protocol sent, such as For example, the transmit control protocol (TCP; TCP = Transmission Control Protocol). An instrument can send an event message. Other instruments can either reply to event messages or ignore them.

Of the Expression "Output Event" refers to an event that causes an event message to appear on the communication network is communicated. It should be noted that not all events are output events are. An instrument can handle some events internally.

Of the Expression "Input Event" refers to an event received by another instrument. The Input event comes in the form of an event message on the Communication network.

The term "action" refers to something that an instrument performs, either in response to an event or to an event message, in certain embodiments provided herein actions are performed using callback routines. In this context, an action is not an atomic event, e.g. For example, a callback routine may execute a complex instruction sequence.

Of the Expression "Programming message" refers to a message sent on the communication network which is used to make a receiver device to program to take a particular action, appealing on the capture of a specific event.

According to the embodiments described herein, event messages are sent over the communications network 14 sent to coordinate the operations of the instruments, such as The source 12 and the recipient 13 , Thus, rather than requiring hardware trigger lines between all instruments used in a measurement system, at least certain instruments are synchronized using the message-based technique described herein. In accordance with at least one embodiment, the event messages include the identification of an event and a corresponding time stamp. The instruments may be configured / programmed to take a particular action in response to the synchronization module receiving a given event, which may be either an event received internally or an event included in an event message (an "input event As further described herein, in certain embodiments, the actions are dynamically programmable 11 a programming message to the source 12 send that their event manager 101B instructs to take a specific action after detecting a specific event. In certain embodiments, the source 12 preconfigured to take the desired action in response to a given event, and is not dynamically programmed in this regard. Thus, since the instruments are programmed (or otherwise configured) to take appropriate actions in response to detected events, event messages that identify events and corresponding timestamps (according to the synchronized local clocks of the instruments) may be used to coordinate the respective operations of the instruments can be used as further described herein.

In the embodiment of 1 include the controller 11 , the source 12 and the receiver 13 each programmed event information, referred to as 102A . 102B respectively. 102C , Such programmed event information may e.g. For example, specify the action (s) that the corresponding instrument will make according to the configuration in response to the specified events. The programmed event information can be z. B. may be arranged as a database or stored in any other suitable manner. In certain embodiments, a user interface is 104 on the controller 11 provided to a user 15 to enable with the event manager 101A to interact, for. For example, to program the event information on the various instruments. Examples of such programmed event information 102A - 102C are further described herein, including the specific example included in Table 2 below.

Since the local clocks of the instruments are synchronized to a high degree of precision, the actions of the various networked instruments can be coordinated with such a high degree of precision. While a message-based approach can be used to coordinate the operations of the instruments, their operations can be coordinated with a higher degree of precision than provided by the message (e.g., due to latencies involved in sending messages over the message) communication network 14 etc.), because the instruments have actively synchronized their local clocks to a high degree of precision.

It is z. For example, assume that the source 12 configured / programmed to change its output frequency changes (eg, RF frequency), in response to detecting "Event # 1", and once the frequency change has settled, the source 12 then issue an event message identifying "Event No. 2. It is further assumed that the receiver 13 configured / programmed to perform a measurement of the signal (eg, power and / or other characteristics of the signal) in response to detection of event # 2. The user 15 In certain implementations, it may initiate the measurement process, through interaction, via the user interface 104 , with the controller 11 to cause an event # 1 to the source 12 is sent. As further described herein, such event # 1 may, in certain implementations, be over the communications network 14 be broadcast. The event manager 101B on source 12 would capture the event # 1 and according to the appropriate programmed action that was in the programmed event information 102B for this event # 1 is identified, change its frequency and subsequently an event message to the receiver 13 send that identifies Event # 2. Again, in certain implementations, this event message sent by the source may be transmitted over the communication network 14 broadcast become. The event message also includes a timestamp based on the local clock 103B the source that corresponds to when the changed frequency has settled (and thus is ready for measurement).

The recipient 13 receives the event message that identifies the event # 2, and the corresponding timestamp, and thus the receiver can 13 perform its programmed action in response to event # 2 based on the corresponding timestamp in the event message. For example, the receiver 13 programmed to take the measurement at the timestamp included in the received event message and that measurement to the controller 11 to send, in response to the detection of an event no.2. Although the receiver 13 After the timestamp that was included in the event message in this example, the event message may be received by the recipient when the recipient receives the event message 13 continuously performs measurements and buffers them, retrieving from its buffer the measurement corresponding to the timestamp included in the message and sending that measurement to the controller 11 send. Thus, the controller receives 11 the measurement corresponding to the exact timestamp included in the event message from the source 12 to the recipient 13 , If the event message from the source 12 to the recipient 13 was delayed to such an extent that the recipient 13 in its buffer the measurement no longer has, which corresponds to the timestamp included in the event message, the receiver can 13 z. B. generate an error.

As another example, the recipient could 13 programmed to respond to the detection of event # 2 by performing a measurement at a time period subsequent to the timestamp included in the received event message, such as the time stamp. 2 seconds after the timestamp included in the received event message and then this measurement to the controller 11 sends. Suppose that the event message is generated and sent over the communication network 14 within 2 seconds of the timestamp included in the message, the receiver may receive this message and make its measurement accordingly (or retrieve the corresponding measurement from its buffer if continuously taking measurements). Thus, the receiver 13 perform its measurement at a time relative to the timestamp included in the event message as opposed to the time the receiver receives the event message. Accordingly, the operations of the source 12 and the recipient 13 time stamp is based on the synchronized clock of the sender of the message, ie the source in the above examples, and is not limited to synchronization operations, based on the time at which the messages are received (which may vary based on network latencies).

Referring to 2 is a specific example of using a message based technique in system 10 (out 1 ) for coordinating the operations of networked instruments. In the example off 2 becomes the controller 11 used to the source 12 at operation block 201 to program. For example, the user 15 with the user interface 104 interact to specify specific information according to which the source 12 should be programmed. In this example, the source becomes 12 programmed to change its frequency at 1:00:00 and then broadcast an event message identifying event # 1. Thus, this information (via a programming message) is provided by the source 12 from the controller 11 received and in their programmed event information 102B saved. Scheduling that an event occur at an absolute time or at a relative time (eg, a time specified with respect to another time, such as "10 seconds after the timestamp, in an event message in this way may be referred to as setting a "time bomb" having an absolute or relative detonation time, after which, after the detonation of such a time bomb, the corresponding device for which the time bomb was set (source 12 in this example) takes a programmed action (changing its frequency in this example). An example of implementing such time bombs and using them to coordinate operations of networked devices is further described in co-pending and commonly assigned German Patent Application Attorney Docket No. AG050618PDE entitled "SYSTEM AND METHOD FOR COORDINATING ACTIONS OF A MULTIPLE OF DEVICES OVER A PLANNING OF THE DEVICES ACTIONS BASED ON SYNCHRONIZED LOCAL CYCLES ", the disclosure of which is incorporated herein by reference.

The control 11 is used to send the receiver to the operation block 202 , For example, the user 15 with the user interface 104 interact to specify particular information according to which the receiver is to be programmed. In this example, the recipient is 13 programmed to take a measurement when event # 1 is detected, and then a round to perform an event message identifying Event # 2. Thus, this information is provided by the recipient 13 from the controller 11 received and in its programmed event information 102C saved.

Further, in this example, the control 11 self-programmed, at block 203 to capture specific events and take response actions. For example, the user 15 with the user interface 104 interact to specify specific information according to which the controller 11 should be programmed. In this example, the controller is 11 programmed to receive measurement data from the receiver 13 to read when event # 2 is detected, and then display the read data. Thus, this information is controlled by the controller 11 received and their programmed event information 102A saved.

At 1:00:00 the time bomb detonates at the source 12 which causes the source 12 their frequency changes generates an event message that identifies event # 1, which acts as an operation block 204 in 2 is shown. As mentioned above, the event message further includes a corresponding timestamp based on the local clock 103B the source 12 , In this example, the source is leading 12 a broadcast of the event message over the communications network 14 using a UDP or other suitable multicast protocol. Techniques that may be used in certain embodiments to use an "unreliable" protocol, such as UDP, in a manner that increases reliability, such as may be desired when the messages are so generated are also described in co-pending and commonly assigned German Patent Application Attorney Docket No. AG050620PDE entitled "SYSTEM AND METHOD FOR STABLE COMMUNICATION ON AN UNRESTRICTABLE PROTOCOL", the disclosure of which is herein incorporated by reference Reference is incorporated.

Thus, the event manager leads 101B the source 12 broadcasting an event message that identifies event # 1 and that includes a corresponding timestamp on the local clock 103B based. For example, the time stamp may be the time 1:00:01, which corresponds to the time at which the changed frequency has settled. It should be noted that the source 12 could be programmed to send the message at the time it starts changing its frequency, and the timestamp included in the event message may therefore correspond to the time at which the source begins the frequency change, in which Case of the receiver 13 may be programmed to perform its measurement at a delayed time relative to the included timestamp to allow the frequency to settle. In this way, the event message may be on the way to the receiver while the frequency change occurs at the source, which may lead to improved measurement efficiency.

The broadcast event # 1 will be sent by the event manager 101A the controller 11 detected, and at the operation block 205 determines such an event manager 101A the controller 11 that no response action by the controller 11 is needed. That is, the controller 11 was not programmed to perform a response action on a received event # 1, and thus the event manager ignores 101A the event message sent by the source 12 was broadcast.

Similarly, the broadcast event # 1 will be the event manager 101C Recipient 13 detected. Because the receiver 13 is programmed (see operation block 202 ) to take a measurement, upon receiving event # 1, at operation block 407 caused the event manager 101C Recipient 13 that such a response action by the recipient 13 is undertaken. As discussed above, the receiver 13 be programmed to perform its measurement on the timestamp included in the event message (the receiver 13 can recover a buffered measurement that it has performed on such a timestamp), or the receiver 13 can be programmed to perform its measurement at a programmed time interval from the timestamp included in the event message, for example.

Like the receiver 13 at operation block 207 was programmed to block 202 perform, the receiver performs 13 a broadcast of an event message that identifies event # 2 and that has a corresponding timestamp based on its local clock 103C includes. The broadcast event # 2 will be sent by the event manager 101B the source 12 captured, and at operation block 208 determines such an event manager 101B the source 12 that no response action by the source 12 is needed. That is, the source 12 was not programmed to execute a response action on a received event # 2, and thus the event manager ignores 101B the event message received by the recipient ger 13 was broadcast.

The broadcast message Event # 2 will also be sent by the Event Manager 101A the controller 11 detected. Because the controller 11 is programmed (see operation block 203 ), the measurement data from the receiver 13 to read and such data after receiving event no.2 at operating block 209 the event manager causes 101A the controller 11 that such a response action by the controller 11 is undertaken. Thus, the controller reads 11 the measurement data from the receiver 13 , For example, the measurement data provided by the receiver 13 be recorded according to the timestamp of the event message that the receiver 13 from the source 12 received at a particular memory address in the receiver 13 be stored, and the controller 11 can block this specific memory address of the receiver 411 read. As another example, the event message received by the receiver 13 is generated, include a timestamp on which its measurement was made (eg, either the same timestamp included in the event message received from the source 12 to the recipient 13 or a timestamp that is a certain interval away from the timestamp included in the event message received from the source 12 to the recipient 13 was sent), and the controller 11 can the receiver 13 after its measurement, query according to the time stamp at which such a measurement is made at block 209 was carried out. Then, at block 2210, control is shown 11 the read measurement data.

In the above example, the controller receives 11 the event message does not identify the event # 2 until a certain time after the measurement by the receiver 13 is performed, and the controller 11 does not read such measurements and does not display them until even later. However, due to the use of the timestamp of the synchronized clocks in the event messages, it can be ensured that the controller 11 displays the appropriate measurement data. For example, if the receiver 13 has performed its measurement at 1:00:01, it can be ensured that the controller displays the measurement data acquired at 1:00:01, even though the controller 11 the measured data z. B. can not receive and display until 1:00:05.

Of course, the application of the embodiments provided herein for synchronizing the operations of the devices is not specific to the specific example 2 limited.

As the above example illustrates, the event manager is 101A - 101C ( 1 ) is based on the IEEE 1588 synchronized clock functionality, but also goes beyond IEEE 1588, by allowing random asynchronous events to be generated and broadcast to other instruments. In certain embodiments, each instrument in a system may be able to circulate an event message on the network whenever an event happens. The list of events that may occur on each instrument may vary from instrument to instrument, and in some embodiments, the actions on each instrument are programmable. For example, a source could be programmed to broadcast an event message whenever the output signal has settled after a frequency change, such as a change in frequency. B. at operation block 204 in the example above 2 or a digitizer could send an event message whenever its input buffer is full. The set of feasible events can thus be defined specifically for each instrument.

Around Receive event messages in certain embodiments, Each instrument is able to "participate" in event messages, that is, each one Instrument should be able to listen for event messages that be broadcast by other instruments (via their respective event manager), and respond accordingly (or ignore) the same.

• 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.

It is z. For example, assume that a measurement is taken that requires a boost converter to change a frequency. The boost converter must settle before the digitizer can read data. The boost converter has a built-in ability to generate an internal event (probably an interrupt) whenever the output signal settles. Using an event manager implemented for such a boost converter and digitizer, this could be accomplished via the following sequence:

• 1. The user sends a command from a control PC to the up-converter, which programs the up-converter to respond to the event "signal settled", which is an internal event predefined in the up-converter As part of the configuration In this event, the user specifies a callback routine, which is called whenever the signal steady state event occurs, and is responsible for broadcasting an event message to other instruments on the network.
• 2. The user programs the digitizer to respond to the event signal "settled signal" from the up-converter Again, a callback routine is specified In this case, the callback routine is responsible for starting a measurement in the digitizer.
• 3. The user sends a command to the up-converter to change the frequency.
• 4. When the output of the up-converter has settled, an internal event is generated and the up-converter's callback routine is called. This results in an event message being broadcast on the network. The message includes an event identifier (eg, "signal settled on up-convertor # 1") and a timestamp.
• 5. The message is received by the digitizer and parsed to determine if the message is relevant or not. Since the digitizer has been programmed to respond to this message, the callback routine is executed and a measurement is started.

It is important to point out that the event messages with timestamp using the IEEE 1588 clock. This allows the Receiver, to stop his answer, if necessary. In that case a digitizer with a ring buffer allows it z. For example, data at the exact time of the original event (or even earlier) even if network latency is the arrival time delay the event message.

It should be noted that the operation may be coordinated by various networked instruments based on events that occur in the devices by generating messages that identify an event and include a timestamp. Of course, like the example 2 For example, the event-based approach can be combined with a time-based approach (using, for example, time bombs to schedule events to occur at scheduled times, either at absolute or relative times). For example, in addition to instrument-specific events, instruments can be implemented to support "time bombs." This allows the user to define the time that an event happens (using the IEEE 1588 clock, with the clocks at each other Instrument in the system is synchronized.) At this time, a user-definable event message may be sent to other instruments on the network, or another internal function may be executed, or both.

• 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.

As another example, the above-mentioned synthetic system of a networked up-converter and a digitizer may have coordinated their operations using a combination of a time-based model and an event-based model, as follows:

• 1. The host computer defines an event message that is used to start a measurement. This new event message is called the "startup" message.
• 2. The boost converter is programmed to switch to a new frequency whenever it receives a "start" event message, more specifically, the "start" message may include a timestamp and the boost converter is programmed to increment to a new frequency switch, at a certain time afterwards. This eliminates network latency and ensures that the up-converter and digitizer operate from the same time base.
• 3. It is known that the output of the up-converter settles after 100 microseconds (μsec). The digitizer is programmed to begin making a measurement 100 μsec after it receives a "start" notification message More specifically, the digitizer can use the time stamp from the "start" message to take a measurement, 100 μsec after the Up-converter switches.
• 4. The host computer broadcasts a "start" event message.

A specific implementation of an event manager is below described in more detail, but embodiments are not intended be limited to this specific implementation.

at In this illustrative implementation, the event manager is on many ways analogous to a network service background routine such. B. one FTP server or a web server - he waits for input and act according to the same. In such an implementation, the event manager is on Listen-only network server, when inputs are handled but its implementation is different yourself for issue events. This illustrative implementation of the event manager can be described as a collection of subprocesses are considered, though not It should be assumed that the event manager is actually under Use of a subprocess model is implemented (this depends on the operating system). The illustrative implementation may be considered a collection of subprocesses be modeled, all on one Wait for type of input. Every subprocess goes to sleep, until its input buffer has data available.

input events arrive on the communication network. The event manager just wait for an event message to arrive, right on the Way in which another network server would do it. If an event message arrives, the event manager wakes up and examines the data packet. If the data packet has an event ID contains (described further below) for which the synchronization module was programmed to respond to the same, the event manager calls the corresponding callback routine.

output events are generated internally. Often output events (eg, time bombs) are the result of hardware interrupts. In this case, an interrupt service routine (ISR; ISR = interrupt service routine) for use on the instrument. The ISR is responsible for capturing a timestamp for the event, saving the data and the waking up of the event manager, who then the appropriate callback routine performs. The ISR is not the same as the callback routine.

Other Events can be handled differently, depending on the hardware / software architecture of the instrument. The event manager allows any callback routine at the time of an event, and that the callback routine can handle the event internally.

at In this example implementation, the event manager is based on Multicast messages. The multicast is usually about the Implemented UDP protocol, not as a high reliability service is designed. Packages can (and do this too) get lost. It is desirable that the event manager the ability has to detect lost packets; but there event messages time critical for most meters, it is often equally desirable avoid the overhead of the handshake protocols, such. As the TCP, is intrinsic.

• 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.

The reliability of the event manager can be improved by using one or more of the following techniques:

• 1. Careful selection of switches. Switches should be selected which have a high level of storage and forwarding capability to minimize packet loss and which implement QoS functionality so that UDP packets can be given a high priority.
• 2. Redundant broadcasting of event messages. Event messages can be broadcast several times to ensure that they are received; the receive modules can be configured to ignore multiple receive events of the same message. Example techniques employing redundant broadcasting of UDP packets to enhance reliability are further described in co-pending and commonly assigned German Patent Application Attorney Docket No. AG050620PDE entitled "SYSTEM AND METHOD FOR STABLE COMMUNICATION ON AN UNRESERVABLE PROTOCOL", the disclosure of which incorporated herein by reference.
• 3. A user-specified timeout for event messages. When a synchronization module "participates" in an event, a maximum time delay is specified for that event When an event message arrives, the time stamp contained in the event message is compared to the current time if the time difference is greater than the given one Maximum, then an error condition occurs, errors may be broadcast on the communication network or sent to the control computer over a TCP connection, as examples.

It are different data types, in this illustrative example an event manager. A first data type is Time. The event manager has two different time-based ones Data types on.

a for the absolute time (TimeStamp = timestamp), and another for time intervals (TimeInterval).

One other data type is Function ID ("FID") The FID is on Value (for example, a 16-bit integer) that has an internal functionality of a Instruments represents. He can be considered an instrument-specific number be implemented, which is used to different functions to identify those who are intrinsic to the instrument.

Instrument functions are classified as "inputs" or "outputs". In this nomenclature, an "output" function is something that happens internally on the instrument and thereby causes an Er event message is sent to other instruments. An "input" function is one that the instrument can execute in response to receiving an event message from elsewhere A time bomb is a special version of an output function for which specific API operations exist (eg, to set the These functions closely correspond to the definitions of "input events" and "output events." More specifically, an "input event" is an event that would result in the execution of an "input function."

at In this example implementation, each instrument has a table from FID values and their descriptions on, as in the example, provided in Table 1 below:

Tabelle 1

Table 1

It It should be noted that some of these features can also have a corresponding hardware trigger (either a trigger input or a trigger output).

One User can programmatically use the Function ID table for a given Expand instrument. If an instrument needs to be programmed, to respond to an external event, z. B. a new one internal function to be added to the table.

One other data type is Event ID ("EID") .The EID is a user-defined one Value (for example, a 16-bit integer), which is included in a broadcast event message Identify event. When entering an event message An instrument reads the EID to determine if it is on the same should or should not respond (for example, to determine if the identified Event is such, for the instrument has been configured / programmed to respond to do). When outputting, the instrument adds the EID add to the event message packet so that other instruments the Identify the source of the event.

in the General allows This allows the user to define EID values that are used with FID values. For example, an instrument may experience a "time bomb" event and the FID for this event is "3" (and is in the Instrument hard-coded). But if an event message as a result When this event is broadcast, the EID value is user-definable and does not have to be equal to the FID.

each individual instrument can preset EIDs for most predefine the FIDs. But the system integrator / end user can the EID values for set / change all FIDs as desired.

Of the User can z. For example, specify EIDs for each instrument in one Test system are unique. Otherwise, problems can be encountered whenever a test system includes several identical instruments. For a For example, given the test system, the user may also provide unique EIDs for the events of each Specify instruments.

A Function ID to Event ID map (function ID for Event ID mapping) is added presented this example implementation.

• (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.

That is, the event manager subsystem at each instrument maintains a FID-to-EID mapping. This can, for. B. implemented as a table. This table retains the mapping between EIDs and FIDs, and also includes other data, such as: B:

• (a) A flag for disabling / enabling each function.
• (b) The (address of) callback function used for the event.
• (c) information about whether the event in question is an input or an output. While time bombs are output events, they may be specially flagged in the table because they have specific API functions associated with them.
• (d) A time-out value. This is used for input events and represents the maximum delay that can be tolerated before an event message is received.

One Example of such a table for an instrument is provided in Table 2 below.

Tabelle 2

Table 2

A given FID in the table represents either an input or an output, but not both. A time bomb is a special type of output function. Table 2 provides an example of information related to the programmed event information 102B the source 12 can be stored. The programmed event information 102B and 102C the controller 11 and the recipient 13 can be arranged in a similar way.

The Enable / disable setting from Table 2 reduces unnecessary traffic over the Communication network for Output events and is used to get relevant event messages for input events to identify. By default, can the individual instrument the state of the enable / disable flag for all Set functions (most are locked), and default EIDs for every function to adjust. It is possible, multiple EIDs for to specify (and release) a given FID. This gives free the event manager to perform the same function if one of the EIDs is received.

• 1. Ereignis-ID
• 2. Zeitstempel
• 3. Anzahl von Bytes, die folgen
• 4. Event-spezifische Daten

Another data type is Event Message Data. According to this illustrative implementation, event messages are of a simple data format and include the subsequent ones Information:

• 1st event ID
• 2. Timestamp
• 3. Number of bytes that follow
• 4. Event-specific data

event messages are sent using the SendEvent () call (event send). Usually this routine is called from within the user callback routines. The Data sent with the event is preferably minimal, to avoid / minimize network latency issues.

Various API functions are provided in this illustrative implementation. An API function is Reset () (Reset). This function sets the event manager to its default (factory) state back. All functions are blocked. Upcoming time bombs and event messages will be canceled. Custom events are deleted.

A other API function is GetCurrentTime () (get current time). This function returns the current value of the IEEE-1588 clock.

A another API function is CreateInputFn (FID) (create input function (FID)). This function creates a new input function with the given FID. The function is generated without EIDs or callbacks and is as an input function marked (not as an output function or a time bomb). She returns an error and does nothing if the given FID is already in use, or if there is not enough memory to expand the function table.

A another API function is DestroyInputFn (FID) (destroy input function). These Function removes the given function from the function table. It sends back an error and does nothing if the given FID does not exist.

A another API function that is provided is SetCall BackFn (FID, CallBackFn, CancelCallBackFn, ErrorCallBackFn, PtrToVendorData) (callback function set (FID, callback function, callback function Clear, Error callback function, Pointer to seller data)). This function sets the callback function for one FID value. The "CallBackFn" (callback function) is called when an event occurs. Formatted for output events the callback function usually an event message and leads broadcasting them on the communication network, though the event manager does not restrict the functionality of the callback. For input events becomes the callback function is called when an event message is received which is on the given Function maps.

The "CancelCallBackFn" is called, always when the function is locked. If the function is already locked is, this callback will not executed. The "ErrorCallBackFn" (error callback function) is for Warnings or errors called. If z. B. a time setting expires, can force that to ignore some time bombs and one Warning / error is caused. The types of errors that cause that This routine is generally instrument-specific. The SetCallBackFN (callback setting function) does nothing and sends back an error when a user tries recalls to assign to a FID that does not exist.

In this example implementation, the following parameters are passed to callback functions:
Function ID
Event ID
time stamp
Seller specific data

Around unnecessary Can avoid function calls any of the callback functions Be zero.

A other API function provided is SetTimeout (FID, MaxYTimeDelay) (Set time out (FID, maxTime delay)). This function provides the maximum time delay one that can be tolerated before receiving an event message becomes. If a received event exceeds by more than MaxTimeDelay (max Time Delay) delayed then an error condition occurs. This feature does nothing and sends back an error, if the given function is not an input function.

MapFIDtoEID (FID, EID) is another API function that is provided. this function maps a given FID to an EID. This function does nothing and sends back an error when a user tries has to map from a FID that does not exist.

UnMapFIDtoEID (FID, ID) is an API function that is an illustration of a given FID of an EID. This brings the picture to the default State back and also blocks the event (see EnableEvent below). These functionality is similar to the EnableEvent call (below), but is used in cases where several EIDs are mapped into a single FID and just the picture should be lifted by one of the EIDs. This feature does nothing and sends back an error, if the given FID / EID pair can not be found.

(False FID, EID, true /) EnableEvent (Release event (FID, EID, true / false) is an API function, which releases an event using FID or EID or both or locks. If the function is an input, it will work for all appearances participate / cancel the participation; and if the function is a Issue, it will release / lock all occurrences of the issue. If a zero for either FID or EID is specified, the parameter is ignored and the other parameter (presumably non-zero) is used.

If the given FID refers to a time bomb, the function should enabled by this function and by a function CreateTimeBomb () (Generate time bomb) (see below). this function EnableEvent can be used to create a Lock time bomb, in which case it does the same as the call CancelTimeBomb () (cancel time bomb). This EnableEvent function does nothing and sends back an error if the FID / EID pair is not can be found.

SendEvent (EID, TimeStamp, Data, Bytes) (send event (EID, timestamp, data, Bytes) is another API function, which is provided. This function performs a broadcast of an event message out. It should be called from within the callback routines and should not be called when the function is locked, although this does not cause a mistake.

Create Time Bomb (FID, TimeStamp, RepeatCount, TimeInterval) (generate time bomb (FID, Timestamp, retry count, time interval) is another one API function that is provided. This feature represents a repeated Time bomb that starts from the given timestamp, then it will for RepeatCount-1 times repeated using the given time interval (so that the total number of detonations RepeatCount is). RepeatCount can be set to -1 for one infinite loop pass can be adjusted. Whenever the time bomb expires, will Call-BackFn for one execution called.

Create Time Bomb (FID, TimeStamp, Frequency) (generate time bomb (FID, timestamp, frequency) is another feature that is a special version of the above Function is. This feature generates a repeated time bomb with repeat count = -1. The time interval is calculated from the frequency parameter.

A other API function that is provided is CancelTimeBomb (FID) (Cancel time bomb (FID)). This feature tries a time bomb cancel. There is no guarantee that the time bomb will be canceled before she fires. In some cases, CallBackFn can do this handle internal flags. This CancelTimeBomb function does the same thing such as EnableEvent () (Release event) when using EnableEvent () is to block a time bomb function. The CancelTimeBomb function sends back an error and does nothing if the given FID does not set a time bomb or if the FID at all there is no time bomb.

GetFunctionMap () (Get Functional Image) is a feature that contains the information returns, which are included in the FID to EID map (defined above). This function can, for. B. used for debugging purposes become.

Of the Event Manager includes a network background routine that follows Commands on the communication network are listening and corresponding API calls on the local processor of the instrument. This functionality gives you one (remote) host computer free to use an instrument for measurement-specific To program tasks. The control computer can z. B. a Program instrument to start a measurement, if one certain event message is received. To do this, send It also gives a programming command to the instrument.

As described above, the event manager also stops after broadcast event messages from their instruments. That is, the event handler of this example implementation comprises two network listening devices: one to listen for event messages from other instruments (listening to a multicast UDP port), and one to listen for remote programming commands (listening to a TCP port) ,

The Network background routine is listening just on a TCP port after commands. Each command can be accompanied by additional data. It should be noted that the allowed commands are the API functions correspond to those described above.

While one detailed implementation of an event manager described above are embodiments not limited to this example implementation. Instead, different ones can Features and Implementation Details Provided Above in alternative embodiments changed become. For example, in certain embodiments, the TCP may be used for Sending event messages are used and not for broadcasting from event messages over UDP. Furthermore, can the various example API functions used in the sample event manager are described above, change, all or some of such Functions can can not be provided and / or additional features may be provided alternative event manager implementations be provided.

Referring to 3 FIG. 12 is an operational flowchart for synchronizing the operation of a plurality of networked devices according to one embodiment. At operation block 31 For example, an event message including an identification of an event and a time stamp is received by at least one of the plurality of networked devices, the devices having synchronized clocks. As described above, in certain embodiments, the event message is broadcast from one sending device to all other devices on the communication network. At block 32 the at least one device that has received the event message determines whether the received event message identifies an event to which the at least one receiving device is to act. As described above, in certain embodiments, the devices may be dynamically programmed in terms of the events to which they are to respond, as well as the specific response actions the device should take for a given event. At block 33 if it is determined that the received message identifies an event toward which the at least one receiving device is to act, then the at least one receiving device is related to the identified event based on the time stamp included in the received message. Thus, the action of the receiving device can be coordinated with the transmitting device based on its synchronized clocks.

Even though the present invention and its advantages described in detail It should be noted that various changes, Replacements and modifications can be made herein without to depart from the invention as defined by the appended claims becomes. Furthermore, the scope of the present application is not intended to the specific embodiments the process, the machine, the manufacturing, the composition of objects, Facilities, procedures and steps are limited in the specification are described. As one of ordinary skill in the art will appreciate can recognize Processes, machinery, manufacture, composition of objects, facilities, Procedures or steps that already exist or are developed later that perform essentially the same function or achieve substantially the same result as the corresponding ones Embodiments, which are described herein. Accordingly, should the accompanying claims within their scope, such processes, machinery, fabrications, Compositions of objects, Facilities, methods or steps include.

Claims (42)

A system comprising: at least two devices ( 12 . 13 ) communicatively via a communications network ( 14 ), wherein the at least two devices comprise means for synchronizing their clocks ( 103B . 103C ); wherein the at least two devices ( 12 . 13 ) means for communicating a message comprising a timestamp identifying an event across the communication network to the other of the at least two devices; and wherein the at least two devices ( 12 . 13 ) comprise means for receiving the message and determining a response action taken in response to the identified event where a particular action is taken based on the timestamp included in the message. System according to claim 1, wherein the means for synchronizing their clocks following Feature: means for implementing the IEEE 1588 standard for synchronization the bars. System according to claim 1, wherein the means for synchronizing their clocks following Feature: a device for implementing a Network Time Protocol (NTP) to synchronize their clocks. A system according to any one of claims 1 to 3, wherein the means for synchronizing its clocks comprises: means for actively synchronizing the clocks through the at least two devices ( 12 . 13 ) that interact with each other. System according to one the claims 1 to 4, where the time stamp is based on the clock of the device, which sends the message. A system according to any one of claims 1 to 5, wherein the means for communicating the message to the other of the at least two devices ( 12 . 13 ) comprises: means for broadcasting the message over the communications network. System according to claim 6, in which the device for broadcasting the message via a User Datagram Protocol (UDP) sends. A system according to any one of claims 1 to 7, wherein the means for receiving the message comprises: means for receiving a broadcast message over the communications network ( 14 ). System according to one the claims 1-8, wherein when the means for determining a response action that determines no action for the identified event should be taken, then the other one Device performs no response action. System according to one the claims 1 to 9, in which the other device with regard to the response action is programmable, responsive to the identified event should be undertaken. System according to one the claims 1 to 10, in which the at least two devices have instruments in a measuring system. System according to claim 11, wherein the at least two devices synthetic instruments are. System according to one the claims 1 to 12, where the other device is the specific response action takes the timestamp included in the received message is. System according to one the claims 1 to 13, in which the other device is the specific answer action at a defined time relative to the timestamp in the received Message. A system comprising: at least two devices ( 12 . 13 ) communicatively via a communications network ( 14 ), wherein the at least two devices synchronized clocks ( 103B . 103C ) exhibit; wherein the at least two devices each comprise an event manager ( 101B . 101C ) operative to receive messages from the other of the at least two devices, the messages comprising information identifying an event and a timestamp; and wherein the event manager is operative to determine whether an action is to be triggered by its corresponding device in response to an identified event in a received message, wherein if it is determined that an action is to be triggered, such an action is based is triggered on the timestamp included in the received message. A system according to claim 15, wherein said at least two devices actively synchronize their clocks thereby chronicle that they interact with each other. System according to claim 15 or 16, in which the at least two devices their clocks synchronize according to the IEEE 1588 standard. System according to one the claims 15 to 17, in which the time stamp is based on the clock of the device, which sends the message. A system according to any one of claims 15 to 18, wherein the event manager is operative to receive the messages transmitted over the communications network ( 14 ) are broadcast. A system according to any one of claims 15 to 19, wherein the event manager is operative to send a message over the communications network ( 14 ). System according to one of claims 15 to 20, wherein the at least one of the devices ( 12 . 13 ) is programmable with respect to the action to be triggered in response to the identified event. System according to one the claims 15 to 21, where the action is triggered on the timestamp, the included in the received message. System according to one the claims 15 to 22, during which the action at a defined time relative is triggered at the time stamp in the received message. System according to one of claims 15 to 23, wherein the at least two devices ( 12 . 13 ) Are instruments in a measuring system. A system comprising: a plurality of devices communicatively communicating over a communication network ( 14 ), wherein the at least two devices ( 12 . 13 ) have synchronized clocks; wherein at least one of the plurality of devices ( 12 . 13 ) an interface ( 104 ) for receiving an input that programs the at least one device to take a defined action in response to a specified event; wherein the at least one of the plurality of devices ( 12 . 13 ) further comprises an event manager operative to receive messages from the other of the plurality of devices, the messages comprising information identifying an event and a time stamp; and wherein the event manager is operative to determine whether an event identified by a received message is an event for which the at least one of the plurality of devices (16) 12 . 13 ) is programmed to take a corresponding defined action and if the event identified by a received message is an event for which the at least one of the plurality of devices is programmed to take a corresponding defined action Event Manager triggers that the at least one of the plurality of devices undertakes the corresponding defined action based on the timestamp of the received message. System according to claim 25, wherein the at least one of the plurality of devices the corresponding defined action at a programmed time after takes the timestamp of the received message. System according to claim 25 or 26 where the event manager is in effect to receive the messages to receive that over the communication network will be broadcast. A method comprising the steps of: receiving ( 31 ), by at least one of a plurality of devices ( 12 . 13 ) communicatively coupled to a communication network, a message comprising an identification of an event and a time stamp; Determine ( 32 ), by which at least one receiving device determines whether the received message identifies an event towards which the at least one receiving device is to act; if it is determined that the received message identifies the event toward which the at least one receiving device is to act, then acting on the at least one receiving device upon the identified event based on the time stamp included in the received message. Method according to claim 28, wherein the at least one receiving device to the identified event nis at a defined time after the timestamp. Method according to claim 28 or 29, further comprising the step of: Receive a programming message by the at least one receiving device, which configures the receiving device to respond to an action to undertake an event. A method according to any one of claims 28 to 30, wherein receiving the message comprises the step of: receiving the message over the communication network ( 14 ) is broadcast. A method comprising the steps of: transmitting a message over a communications network ( 14 from a first device to at least one other device, wherein the message identifies an event and includes a timestamp; Receiving the message by the at least one other device; Determining, by the at least one other device, whether the event identified in the received message is feasible; and if it is determined by the at least one other device that the identified event is feasible, the enterprise of an action by the at least one other device in response to the identified event based on the timestamp included in the message. Method according to claim 32, in which the action taken by the at least one other device will, on a desired Way with an action being synchronized by the first one Device is taken. Method according to claim 32 or 33, in which the transmission has a broadcast. Method according to one the claims 32 to 34, during which the enterprise of an action by the at least another device responsive to the identified event the following step: Company of a measurement. Method according to one the claims 32 to 35, wherein the performing an action by the at least one other device appealing following the identified event based on the timestamp Step has: Company of action to a defined Time relative to the timestamp. Method according to one the claims 32-36, where the timestamp on a local clock of the first Device based, and the local clocks of the first device and the at least one other device is actively synchronized become. A method comprising the steps of: programming a device to define an action to be performed by the device in response to a specified event; Receiving, by the device, messages from a communications network ( 14 ) of at least one other device with which the device is temporarily synchronized, the messages each identifying an event and including a time stamp; Determining, by the device, whether an event identified by a received message is the specified event; and if the event identified by a received message is the specified event, then the entity of the defined action by the device based on the timestamp of the received message. Method according to claim 38, where the action defined the company of a measurement is. Method according to claim 38 or 39, in which local clocks of the device and the at least another device will be actively synchronized. Method according to claim 40, where the local clocks over an item to be synchronized selected from the group consisting out: IEEE 1588 and network timing protocol (NTP). Method according to one the claims 38 through 41, in which the device that the defined action based on the time stamp, has the following feature: Companies the defined action at a programmed time relative to that Time stamp.