Patent Application
20080059106
An instrument 2, as just described, is shown as being coupled for communication to a communication network 4, which can be the Internet, a local area network, etc. In an embodiment of the invention, an on-board test apparatus, shown as embedded test software 6, is provided within the instrument 2. The test software 6 will be described in more detail below.
The network 4, being a general purpose communication network as described above, may also have a variety of devices, pieces of equipment, communication nodes, etc, coupled for communication over it. In an embodiment of the invention, a test controller 8 is shown as coupled for such communication over the network 4. The test controller may be in proximity to the instrument 2, or may be at a remote location, for the system architect's or the test operator's convenience. To illustrate this point without limitation, the test controller 8 is labeled as being a “remote” test controller 8. The test controller 8 communicates with the instrument 2, to operate the on-board test apparatus (for instance, to cause the embedded test software 6 to execute), by means of communications over the network 2.
By contrast, conventional test solutions have employed troubleshooting applications resident on test systems such as production line UNIX workstations, employing software written in Basic, C, shell scripts, etc. These conventional applications have required a IEEE 488 General Purpose Interface Bus (GPIB) connection between the UNIX workstation and the instrument. It will be seen, then, that the conventional test systems have had to be transported to the location of the instrument to be tested, and the GPIB bus has had to be installed separately from the network 2.
Such a required GPIB connection, or the like, has limited the ways in which system operators have been able to perform tests. For instance, it has not been possible to install test software on the equipment for testing controlled remotely, at the behest of commands sent by a remote system operator over a standard communication network such as a Local Area Network (LAN).
In the illustrated (
Also, since the test software 6 is on-board the instrument 2, it is also possible for a customer/operator of the instrument 2 to operate the test software 6 in an embedded or stand-alone mode. This is done by using a local user interface (not shown), which may include a display, keyboard and mouse interface, etc. In one embodiment, the interface is Windows-based. The operator of the instrument 2 uses the interface devices to give local test commands to cause the embedded test software 6 to execute without the need of an external controller 8.
The remote test controller 8 may be located in a service center. For instance, the service center might operate subscriber services, in which a service center operator performs routine testing, troubleshooting of reported problems, performance surveys, etc., for instance by performing a remote desktop connection log-in sequence on an instrument 2 having a Windows-based or other standard user interface, and dispatching test commands over the network 4 to the instrument 2. The instrument 2 executes the tests responsive to the test commands.
For statistical surveys, it is possible to accumulate test reports, which are sent back to the test controller 8 from remote equipment such as the instrument 2,as replies to the test commands. For instance, a memory storage device such as a store 10 may be provided, for instance at the same location as the test controller 8. The store 8 receives test reports transmitted over the network 4 from equipment such as the instrument 2.
The store 10 may be coupled to the test controller 8, either over the network 4 or by a dedicated link 12, to enable the test controller 8 to access and process the test results. In one embodiment, the store 10 may be coupled directly to the network 4, to monitor network traffic, and receive and store all test reply messages addressed to the test controller 8. As test reports accumulate in the store 10, statistics can be calculated, and human-viewable presentations, such as graphics, can be prepared for display.
A more detailed description of the operation of the embodiment of
A test command is received (14), either as a remote command transmitted from the test controller 8 over the network 4, or as a command entered locally by an instrument operator through a user interface of the instrument 2. As noted above, the instrument 2 may employ a Windows-based user interface, or the like. In such cases, the above-mentioned command may also include a Windows log-in sequence, etc.
The test software 6 receives and identifies the command, and performs testing operations (16) appropriate for the type of equipment the instrument 2 is, the type of operation of the instrument 2 that is to be tested, and the type of test report that is desired. Test result data is generated.
The test software 6 then formats the test results (18) into a format suitable for responding to the test command. This can include either formatting (such as packetizing) for transmission over the network 4 to the test controller 8, or formatting in a way suitable for a user interface of the instrument 2, depending on whether the testing is by remote command or in the embedded mode responsive to instrument operator command. Then, the results are either transmitted or displayed locally, as appropriate (20).
In one embodiment, the embedded/remote diagnostic applications are written in the C# language, using the .NET Framework. Communication between the test controller and instruments to be tested is done with SCPI commands using code from the Agilent Test and Measurement Toolkit. Graphical representations of the resultant test data are created using code from the Agilent Test and Measurement Toolkit.
In the case where (14) includes receiving a test command transmitted from the remote test controller 8, the operation of the test controller 8 may be as shown in the flowchart of
At a remote test center, a human operator or automatic test scheduler generates a test command (22) which, as noted above, may include a log-in sequence, etc. The test command is addressed to a particular piece of equipment at a particular location. The test command instructs that a particular test, or sequence of tests, shall be performed. Such test or sequence of tests is appropriately chosen, based on factors such as the type of equipment or instrument to be test, the nature of its operation, the type of test desired to be run, the type of performance information desired to be obtained, etc. Where a performance history is being maintained, or a survey of test information is sought over a population of instruments (for instance, the same type of instrument, or instruments performing the same type of function, etc.), the test command might be part of a schedule or list set up to support such history or survey.
The test command is transmitted over the network (24), and the test controller 8 waits for a test report in response.
When the instrument 2 transmits (20) the test results report, the report is received (26). The report may be received by the test controller 8 and processed directly. Alternatively, the test controller 8 may store the report in the store 10, by way of the dedicated link 12 or the network 4. In another alternative, the store 10 may directly receive the report from the network 4. If the store 10 has sufficient intelligence, processing capability, etc, it can store and catalog the report for subsequent access by the test controller 8.
The test controller 8 then processes (28) the test results. Such processing can include arrangement into a suitable format for display (30), comparison with previously stored results, compilation of statistics, etc.
The test results, statistics, etc, are displayed (30). Such processing (28) can also include formatting the report for display to the test controller operator.
In alternative embodiments, a graphical test display either (i) updates as the test runs, or (ii) appears at the end of the test. Updating as the test runs may be employed for long-running tests. This “graphically update as you test” can also plot several data variables at once.
In some test applications, graphs may be used, to allow the user to optionally retain existing data plots, when rerunning the test application to generate new data plots. This allows the user to observe the repeatability of the device under test, over multiple test runs. Alternatively, the user interface may be refreshed with new data plots, as the test continues to run, or is re-run.
Where graphs (i.e., with x and y axes) are displayed, either or both of the axes may be autoscalable, such as by user command. Such autoscalability may be useful, for instance when the range of the data cannot easily be anticipated.
Test results may be presented in a hierarchy of displays, menus, etc. From a parent display, the user can use click display buttons, pull-down menus, etc, to view additional report information, such as a list or graph of test results, which otherwise would not be part of the displayed information. In one embodiment, the parent test result display could include an overall PASS or FAIL test sequence result. The user then selects a child test result display, perhaps from a set of alternative child displays. Such parent/child test displays can, for instance, be used where the main user interface form is crowded and extra screen real estate for test results is unavailable.
Although the present invention has been described in detail with reference to particular embodiments, persons possessing ordinary skill in the art to which this invention pertains will appreciate that various modifications and enhancements may be made without departing from the spirit and scope of the claims that follow.
