Patent Application
20080126868
The present invention relates to diagnostic testing for electronic equipment.
Conventional diagnostic testing arrangements have involved coupling a test system, such as a production line Unix workstation, to an instrument or piece of equipment to be tested. Troubleshooting software applications, in the form of BASIC or C language programs or shell scripts, etc., reside within the test system.
When such troubleshooting software applications are executed, the test system, and the instrument to be tested, communicate through a communication interface. For instance, many such troubleshooting applications use an IEEE 488 General Purpose Interface Bus (GPIB) connection between the UNIX workstation and the instrument.
It would be advantageous to employ standard network communications for such diagnostic testing, obviating the need for a diagnostic-specific interface such as the GPIB and allowing for remote testing. It would also be advantageous to execute diagnostic testing on-board the equipment to be tested.
A method is provided for performing a diagnostic test on a piece of equipment, the equipment including a plurality of components, each of the components including a diagnostic test result store. The method comprises executing a diagnostic test by means of a diagnostic apparatus embedded within the piece of equipment, determining, based on the results of the diagnostic test, that one of the components is diagnosed to be faulty, preparing a report of results of the diagnostic test within the diagnostic test store of the faulty component; and storing the report in a test report store on-board the diagnosed faulty component.
Further features and advantages of the present invention, as well as the structure and operation of preferred embodiments of the present invention, are described in detail below with reference to the accompanying exemplary drawings.
A system embodying the invention includes self-contained embedded diagnostics for a piece of electronic equipment. Among other fields, such a system may be employed in a measurement apparatus for radiofrequency (hereinafter “RF”) systems.
Initial testing of factory-manufactured equipment before shipment to the user/customer may easily be performed. However, once a piece of equipment leaves the factory and a user begins using it, it is notoriously difficult to receive good failure data from the field. In such systems, it is desirable to be able to self-diagnose problems which can be solved by replacing components of the equipment, such as sub-assemblies, cables, etc., without requiring the use of external test and measurement equipment. When such a problem is diagnosed, service personnel not necessarily requiring great expertise or training, can replace the faulty component.
For instance,
In
Additionally, each component 16 contains a diagnostic test fault report store 20, such as an electrically erasable programmable read-only memory (EEPROM). As will be described in detail below, diagnostic test results are stored in the fault report store 20.
In the discussion which follows, the term “indicted” will be used to describe a component, sub-assembly, etc., of the equipment 2, for which a problem has been diagnosed. Also, the terms “component” and “communication component” will be used interchangeably, to refer broadly and without limitation to any sub-assembly, cable, interface, component, etc., within a communications system, for which a fault may occur. The term “fault” will refer to any problem that is, or can be, isolated within a particular component of the communication system. Finally, the term “device under test” or “DUT” will be used to refer to the equipment 2 to be tested.
A diagnostic performed by a system embodying the invention can identify an indicted component, a failing component, or the component most likely to fail or to have failed. Also, the particular nature of the fault or failure can be identified.
Responsive to the test command, the test controller sends (24) a test signal to exercise the equipment 2, and to detect and obtain test information regarding how the various components of the equipment 2 are behaving. The detected test information is analyzed (26) to determine whether the components are functioning normally, or whether an abnormality that may be indicative of a fault or problem has been detected.
Based on that analysis, it is determined (28) first, whether a fault has been detected, and second, based on which test points show which abnormalities, which component seems to be faulty. If no fault is detected, the test apparatus idles or performs other functions until another test command (22) is received.
If a fault is detected, the faulty component, and the nature of the fault, are analyzed (30), and a report is prepared (32). The report is stored in the fault report store 20, and/or displayed or printed to the system operator (32), through a user interface, printer, display, etc. The report may also be transmitted to the remote test controller 12.
Analyzing (30) the faulty component and the nature of the fault can include multiple levels. That is, where a faulty component 16 includes multiple sub-components 18, the tests and the analysis of their results can make it possible to further isolate the fault to one of the sub-components 18.
The diagnostic application can identify the most likely failing sub-component 18, within a diagnosed faulty component 16, and provide to the EEPROM fault report store 20 of the faulty component 16 a report of the fault within the indicted component 16. Such fault report information, stored within the failure report store 20 of the faulty component 16, allows technicians to quickly repair faulty components, which conventionally would have accumulated as faulty components (sometimes called “dog board” piles) awaiting repair.
The suspect component can be loaded into a specially designated diagnostic system (sometimes called a “system mule”), and the EEPROM queried to gain insight as to the likely failure mechanism.
Alternatively, when a faulty component is shipped back to the factory or a service center, a system embodying the invention now provides a means of establishing how an instrument failed in service. The factory or appropriate user can use an embedded tool to read back the low-level sub-component failure detail from the fault report store 20. This aids in understanding the failure mechanisms of the component 20 under service conditions.
The report may be in a form that will direct the operator to replace the component believed to be faulty, such as a display or a printout. Where an operator does not necessarily have great expertise with the equipment but has facility with swapping components in and out, the report is sufficient to enable the operator to take action that will enable the equipment to keep on functioning.
The form and content of the report can be analogized to an incident in Arthur C. Clarke's science fiction novel 2001: A Space Odyssey. The HAL 9000 computer on board the spacecraft Discovery directed astronaut David Bowman to replace the AE-35 unit, which was reported to be faulty and, if it were to fail, would have disabled the communication link to Earth. Astronaut Bowman then performed an extravehicular activity to replace the AE-35 unit.
Optionally, the displayed report can include a header such as that shown within the box near the top of
Information displayed in the report may include items such as those shown in the lower part of
Note that, where more than one sub-component within the faulty component may be faulty, the information in items (iii) and (iv), above, may be given multiple times for each of the sub-components likely to be faulty, for instance for every sub-component whose score is above a predetermined threshold.
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.
