US20070260932A1 - Event log management system - Google Patents

Event log management system Download PDF

Info

Publication number
US20070260932A1
US20070260932A1 US11/402,113 US40211306A US2007260932A1 US 20070260932 A1 US20070260932 A1 US 20070260932A1 US 40211306 A US40211306 A US 40211306A US 2007260932 A1 US2007260932 A1 US 2007260932A1
Authority
US
United States
Prior art keywords
event
issue
events
tester
captured
Prior art date
Legal status (The legal status is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the status listed.)
Abandoned
Application number
US11/402,113
Inventor
Ryan Prichard
Ben Rogel-Favila
Current Assignee (The listed assignees may be inaccurate. Google has not performed a legal analysis and makes no representation or warranty as to the accuracy of the list.)
Verigy Singapore Pte Ltd
Original Assignee
Verigy Singapore Pte Ltd
Priority date (The priority date is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the date listed.)
Filing date
Publication date
Application filed by Verigy Singapore Pte Ltd filed Critical Verigy Singapore Pte Ltd
Priority to US11/402,113 priority Critical patent/US20070260932A1/en
Assigned to AGILENT TECHNOLOGIES INC reassignment AGILENT TECHNOLOGIES INC ASSIGNMENT OF ASSIGNORS INTEREST (SEE DOCUMENT FOR DETAILS). Assignors: PRICHARD, RYAN, ROGEL-FAVLLA, BEN
Assigned to VERIGY (SINGAPORE) PTE. LTD. reassignment VERIGY (SINGAPORE) PTE. LTD. ASSIGNMENT OF ASSIGNORS INTEREST (SEE DOCUMENT FOR DETAILS). Assignors: AGILENT TECHNOLOGIES, INC.
Priority to JP2007099885A priority patent/JP2007293840A/en
Priority to SG200702619-8A priority patent/SG136891A1/en
Priority to KR1020070035168A priority patent/KR20070101163A/en
Priority to CNA2007100794909A priority patent/CN101118534A/en
Priority to DE102007017012A priority patent/DE102007017012A1/en
Publication of US20070260932A1 publication Critical patent/US20070260932A1/en
Abandoned legal-status Critical Current

Links

Images

Classifications

    • GPHYSICS
    • G06COMPUTING; CALCULATING OR COUNTING
    • G06QINFORMATION AND COMMUNICATION TECHNOLOGY [ICT] SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES; SYSTEMS OR METHODS SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES, NOT OTHERWISE PROVIDED FOR
    • G06Q50/00Systems or methods specially adapted for specific business sectors, e.g. utilities or tourism
    • G06Q50/04Manufacturing
    • GPHYSICS
    • G06COMPUTING; CALCULATING OR COUNTING
    • G06FELECTRIC DIGITAL DATA PROCESSING
    • G06F11/00Error detection; Error correction; Monitoring
    • G06F11/22Detection or location of defective computer hardware by testing during standby operation or during idle time, e.g. start-up testing
    • G06F11/2205Detection or location of defective computer hardware by testing during standby operation or during idle time, e.g. start-up testing using arrangements specific to the hardware being tested
    • G06F11/2215Detection or location of defective computer hardware by testing during standby operation or during idle time, e.g. start-up testing using arrangements specific to the hardware being tested to test error correction or detection circuits
    • GPHYSICS
    • G06COMPUTING; CALCULATING OR COUNTING
    • G06FELECTRIC DIGITAL DATA PROCESSING
    • G06F11/00Error detection; Error correction; Monitoring
    • G06F11/30Monitoring
    • G06F11/34Recording or statistical evaluation of computer activity, e.g. of down time, of input/output operation ; Recording or statistical evaluation of user activity, e.g. usability assessment
    • G06F11/3466Performance evaluation by tracing or monitoring
    • G06F11/3476Data logging
    • HELECTRICITY
    • H01ELECTRIC ELEMENTS
    • H01LSEMICONDUCTOR DEVICES NOT COVERED BY CLASS H10
    • H01L21/00Processes or apparatus adapted for the manufacture or treatment of semiconductor or solid state devices or of parts thereof
    • H01L21/02Manufacture or treatment of semiconductor devices or of parts thereof
    • GPHYSICS
    • G06COMPUTING; CALCULATING OR COUNTING
    • G06FELECTRIC DIGITAL DATA PROCESSING
    • G06F2201/00Indexing scheme relating to error detection, to error correction, and to monitoring
    • G06F2201/86Event-based monitoring

Definitions

  • the present invention relates generally to test system reliability monitoring, and more particularly to systems and methods for application specific event log management.
  • ATE Automated Test Equipment
  • ATE allows automated testing of integrated circuits and is therefore of paramount importance for achieving reliable high volume manufacturing of such devices.
  • ATE may be linked to a wafer prober to test semiconductor wafers prior to dicing and packaging into individual integrated circuit devices.
  • ATE may also be linked to a device handler to test packaged devices.
  • the combination of ATE with a wafer prober and/or device handler is often referred to as a test cell.
  • test cell is the cornerstone in the implementation of a semiconductor manufacturer's test strategy for a manufacturing facility.
  • failure of a test cell can lead to loss of significant revenue if not addressed expediently.
  • test cell reliability applies generally to all test equipment, especially automated test equipment, or hereinafter simply “testers”, that are distributed in a high-volume manufacturing facility.
  • Embodiments of the invention include methods and apparatus for monitoring tester reliability.
  • an event log management system comprises a data store which stores at least one tester configuration file, a hardware independent event capture function which captures events from at least one monitored tester, each associated with a corresponding test configuration file, a graphical user interface which receives issue information from a user, and a server which receives the issue information from the graphical user interface and creates an issue data element corresponding to the issue information, and which receives the captured events from the event capture function and stores the captured events in an event store, associating respective captured events with corresponding respective issues.
  • a method for managing events of at least one tester comprises obtaining at least one tester configuration file, automatically capturing events from at least one monitored tester associated with one of the at least one test configuration files using a hardware independent interface, receiving issue information, and providing a server which creates an issue data element corresponding to the issue information, and which stores the captured events in an event store, and associates respective captured events with corresponding respective issues.
  • an Event Log Management System comprises a data store which stores at least one tester configuration file, each tester configuration file implemented in XML and comprising one or more event type definitions and corresponding attribute definitions, a hardware independent event capture function which captures events from at least one monitored tester associated with one of the at least one test configuration files, a Web enabled graphical user interface which receives issue information associated with a user perceived condition from a user, and a server which creates an issue file implemented in XML corresponding to and encapsulating the issue information, and which encapsulates captured events captured by the hardware independent event capture function in respective issue files corresponding to respective issues to which the respective captured events are associated.
  • FIG. 1 is a block diagram illustrating networked use of an Event Log Management System
  • FIG. 2 is a block diagram illustrating an exemplary embodiment of an Event Log Management System
  • FIG. 3 is a diagram of an event
  • FIG. 4 is a diagram of an issue
  • FIG. 5 is a perspective view of a tester that may be monitored by the Event Log Management System
  • FIG. 6 is a functional block diagram illustrating the functional logic of an exemplary embodiment of event log management software
  • FIG. 7 is a functional block diagram illustrating the functional logic operation of an exemplary embodiment of a Web GUI
  • FIG. 8 is a screen shot of an exemplary embodiment of an event summary report presented by the Web GUI of the Event Log Management System.
  • FIG. 9 is a screen shot of an exemplary embodiment of an event detail report presented by the Web GUI of the Event Log Management System.
  • Embodiments of the invention presented herein describe systems and methods to identify, acquire, store, analyze, and report fundamental test cell data that enables the monitoring and improvement of the tester reliability, thereby helping to maximize the time the test cell is up and running normally.
  • FIG. 1 is a block diagram illustrating the use of an Event Log Management System 100 a monitoring a number of testers 120 a , 120 b , 120 c , 120 d , 120 e , 120 f .
  • Testers 120 a , 120 b , 120 c are located at site 110 a
  • testers 120 d , 120 e , 120 f are located at site 110 b .
  • a number of users 130 a , 130 b , 130 c may connect to the Event Log Management System 100 a via a web browser to interact with the system 100 a.
  • a site may be physical or logical.
  • a site may be a physical geographical location, and/or a site may be a logical distributed fleet of testers under common business control.
  • One or more additional Event Log Management Systems 100 b may monitor another number of testers 120 g , 120 h , 120 i , which may or may not be located at a number of different respective sites 110 c .
  • a number of users 130 d , 130 e may connect to the Event Log Management System 100 b via a web browser to interact with the system 100 b.
  • FIG. 2 is a block diagram illustrating an exemplary embodiment of an Event Log Management System 200 that may implement the Event Log Management System(s) 100 a , 100 b of FIG. 1 .
  • the system 200 includes an Event Capture module 202 , an Application Program Interface (API) module 204 , a Server module 206 , a Web GUI module 208 , and an event store 210 .
  • One or more testers 220 a , 220 b , 200 m are monitored by the system 200 .
  • the testers 220 a , 220 b , 200 m generate events that reflect the operating state of one or more components of the respective testers 220 a , 220 b , 200 m .
  • the Event Log Management System 200 captures, indexes, and stored the captured events in the event store 210 .
  • Users 230 a , 230 b , 230 n may request various reports relating to the stored events and may enter event data manually.
  • An event is a specific occurrence of an operating state of a given tester as defined in a tester configuration file corresponding to the tester. Events may be captured automatically through the use of the event capture module 202 . Events may also be entered into the system manually by a user through the Web GUI 208 .
  • FIG. 3 illustrates an exemplary test system event 300 diagrammatically.
  • each test system event 300 comprises a date and time stamp 310 , a system ID 320 (for example, a hostname), an event type 330 , and a location 340 .
  • An event may include additional attributes (not shown) depending on the value of the event type.
  • the possible event types and corresponding attributes may vary from application to application, and are configurable by way of a tester configuration file, which in an exemplary embodiment is implemented as an XML file.
  • the event type 230 of a given event may be one the following types: Diagnostic failure: A diagnostic test failed.
  • a calibration for example, a Programmable Power Supply (PPS), Pin Electronics (direct current) (PE DC), Pin Electronics (alternating current) (PE AC), Algorithm Pattern Generator (APG) etc.
  • PPS Programmable Power Supply
  • PE DC Pin Electronics (direct current)
  • PE AC Pin Electronics (alternating current)
  • APG Algorithm Pattern Generator
  • the event location 240 may be one of likewaterleaks dockingproblems,and the following:
  • a site 110 a , 110 b , 110 c (perhaps corresponding to a particular geographical location) is a set of systems.
  • a system might be a particular tester 120 a , . . . , 120 i , such as a test cell.
  • a system may comprise a plurality of modules such as PPS, PE, APG, etc.
  • a module may comprise several sub-modules (for example, four quadrants in the PE module). Sub-modules may be further sectioned (for example, into sub-quadrants).
  • Issues are a higher level abstraction of one or more events. Essentially, an issue describes what the actual problem was, rather than its collective symptoms (which are the events). In other words, issues encapsulate events. As an example, suppose a given tester generates a diagnostic failure event, a configuration change event (from swapping boards to see if the failure will follow the board), and then another diagnostic failure. These events may all relate to the same issue, which may be, for example, that the site module is defective and needs to be replaced. Thus, the issue is what the technician sees and works with, while the events are the low level detail that the vendor is concerned with. Issues may be entered into the system manually by a user through the Web GUI 208 .
  • FIG. 4 illustrates an exemplary issue 400 diagrammatically.
  • an issue 400 comprises one or more attributes such as a date/time 410 , an issue ID 420 , an issue description 430 , an issue location 440 , and a list 450 (or pointers to) one or more events associated with the issue.
  • the Server 206 manages the event store 210 , which is a central storage location for storing details of events and issues.
  • the Server 206 aggregates the information from all tester and user clients that have been configured to use the Server 206 .
  • a single Server 206 services all clients in operation.
  • multiple Servers 206 service subsets of the clients.
  • one Server 206 may service clients in one or more geographical locations, while another separate Server 206 may service clients in another geographical location.
  • system 100 a in FIG. 1 serves testers at sites 110 a and 110 b
  • system 100 b serves testers at site 110 c .
  • data may be exported and imported from one Server 206 to another, thereby allowing data to be aggregated into one logical Server 206 for analysis.
  • event and issue data may be exported from system 100 b to system 100 a , or vice versa.
  • the Server 206 also implements the functional logic that provides the user with web access to provide detailed information on new events and issues, and to edit and analyze existing issues.
  • the process of testing ICs using a tester such as an ATE test cell generates large amounts of data. Some of this data relates to the characteristics of the ICs themselves. Other parts of this data relates to the interactions between the ICs and the test cell, while another part of this data relates to the states and general operating conditions of the test cell.
  • test cell reliability depends to some extent on this test sequence. For example, some test sequences may stress the test cell more than other test sequences, leading to potentially more failures over time.
  • the Event Capture module 202 automatically adapts to any programmed test sequence and automatically captures events from monitored testers which reflect the state and operating conditions of the monitored testers at any selected time.
  • the Event Capture module 202 comprises software code configured to receive events from monitored test devices. Events from each monitored test device may be configured differently, and is defined in a tester configuration file associated with the tester that generates the event.
  • the Event Capture module 202 communicates with each monitored tester using a published API (as implemented in the API module 204 ).
  • the API module implements an Application Program Interface that allows an application or software component (e.g., ATE system software, a software tool or even a customer application utilizing the Event Log Management System 200 ) to log an event with detailed information to the Server 206 .
  • an application or software component e.g., ATE system software, a software tool or even a customer application utilizing the Event Log Management System 200
  • the Event Log Management System utilizes a published API which defines a clear interface with which testers need to adhere to in order to store its data effectively.
  • the advantage of publishing the API to the customers is that if a customer wishes to extend the Event Log Management System 200 to capture events and track issues for other types of devices (such as handlers, ovens, or other testers), the manufacturer of a specific device need only publish its own Event Log Management System configuration file (describing different event types and their attributes) and ensure its software adheres to the API.
  • the Event Log Management System utilizes “Web Services”, a well-known universal standard that supports interoperable machine-to-machine interaction over a network.
  • Web Services Description Language (WSDL) is used in combination with Simple Object Access Protocol (SOAP) and Extensible Markup Language (XML) Schema to provide web services over the internet.
  • SOAP Simple Object Access Protocol
  • XML Extensible Markup Language
  • WSDL describes the public interface to the web service.
  • WSDL is an XML-based service description on how to communicate using the web service; namely, the protocol bindings and message formats required to interact with the web services listed in its directory.
  • the supported operations and messages are described abstractly, and then bound to a concrete network protocol and message format.
  • SOAP is a protocol for exchanging XML-based messages over a computer network, normally using HyperText Transfer Protocol (HTTP) to transfer or convey information on the World Wide Web.
  • HTTP HyperText Transfer Protocol
  • Web Services, WSDL, XML, and SOAP are well-known in the art and are described in detail at http://en.wikipedia.org/wiki/Web_services.
  • the API 204 also provides a mechanism for feedback that triggers the Web GUI 208 for an event so that the user can provide additional information for an event (e.g., to allow the technician to enter notes to the event).
  • the API 204 may also transparently provides a fail-back mechanism in case a Server 206 is not available (for example, due to network problems) that provides essential tracking capabilities offline.
  • a server 206 is unavailable, an event generating tester 220 will cache each generated event to its local data store (such as a local hard drive). Each time an event is generated, the tester first attempts to purge all “cached” events to the server 206 . If the Server 206 is available, the cached events are purged to the Server 206 and the cache is emptied. If the Server 206 is unavailable, the tester 220 will continue caching events.
  • the Web GUI 208 implements a graphical user interface that allows a user to interact with the event log management system.
  • the Web GUI 208 is Web-enabled to allow a user to access the system 200 using only a Web browser and a network connection.
  • the GUI functionality is stored on the Server 206 itself, thereby eliminating the need for special software at the user clients 230 a , . . . , 230 n.
  • the Web GUI 208 serves the two main purposes of issue/event input and issue/event reporting.
  • the Web GUI 208 allows the user to specify (and also, to an extent, modify) additional data for issues and events that are logged to the Server 206 .
  • issues are set up and entered through the GUI 208 .
  • an event often includes a Notes attribute that allows the user to enter additional notes associated with the event.
  • the server 206 may trigger the Web GUI 208 when it receives a new event from a monitored tester to allow the user to provide additional information on an event or assign it to an issue.
  • FIG. 5 illustrates an exemplary embodiment of a tester 500 , specifically an Agilent Versatest V5500 (manufactured by Agilent Technologies, Inc. of Palo Alto, Calif.), that may be monitored by the Event Log Management System 200 of FIG. 2 .
  • the Versatest V5500 500 comprises test head 510 with DUT (Device under test) interface 520 , a manipulator 530 for positioning test head 510 , DUT board 550 which plugs into underlying DUT interface 520 , support rack 540 for supplying test head 510 with electrical power, cooling water and compressed air (not shown in the Figures).
  • Test head 510 comprises tester electronics including pin electronics (PE), programmable power supplies (PPS), algorithmic pattern generators (APG) and additional analog modules.
  • Test head 510 is configured with a number of pins, for example 4096 pins.
  • the test head supports 36 card cages. Each card cage can contain 9 digital boards or 9 analog modules, respectively.
  • the DUT is mounted on DUT board 550 , which is connected to the I/O channels by DUT interface 520 .
  • DUT interface 520 consists of high performance coax cabling and spring contact pins (pogo pins) which establish electrical connection with DUT board 520 .
  • General-purpose manipulator 530 supports and positions test head 510 , providing precise and repeatable connections between test head 500 and handlers or wafer probers.
  • Support rack 540 is attached to manipulator 530 and serves as the interface between test head 510 and AC power, cooling, and compressed air.
  • the tester 500 may include a display 562 , a keyboard 564 , and a mouse (not shown), which may serve as the interface between the user and tester 500 .
  • Other input and output devices may also be communicatively connected to the tester 500 .
  • Test software may execute on a computer or workstation 570 to allow a user to configure and set up tests, and observe test status and test data
  • the Web GUI of the Event Logging and Reporting Software 590 displays Web pages on a user's display 562 and receives user input via the Web interface.
  • FIG. 6 is a functional block diagram illustrating the functional logic of an exemplary embodiment 600 of the event log management software 590 .
  • the software 600 includes an Event Capture module 602 , an Application Program Interface (API) module 604 , a Server module 606 , a Web GUI module 608 , and an event store 610 .
  • API Application Program Interface
  • the Server 606 includes a connection handler function 651 which establishes connections and maintains the connections between the Event Log Management System 600 and the monitored testers 620 a , 620 b , 620 m.
  • Test cells that are monitored by the system 600 each have a corresponding test configuration file.
  • the tester 620 a has a corresponding tester configuration file 640 a stored in the event store 610 of FIG. 6 .
  • Each tester configuration file 640 a , . . . , 640 m is specific to its corresponding tester 620 a , . . . , 620 m .
  • the tester configuration files 640 a , . . . , 640 m are implemented as XML files, storing XML data comprising three categories of information pertaining to a given test cell:
  • the tester configuration files 640 a , . . . , 640 m are stored directly within the system's own database (i.e., the event store 610 ).
  • TABLE 1 A key to the TestCell.xml file describing the contents is shown in TABLE 1.
  • TABLE 1 Element Type Description Event Name Name of type of event.
  • textField Name Name of text attribute comboBox Name
  • comboBox attribute option value Option associated with a comboBox textArea Name
  • the logic implementing the Web GUI 608 runs on the Server 606 and not on the client(s). Therefore, the end user needs only to have access to a web browser to access the Event Log Management System 600 .
  • version control of the GUI is simple and universal, requiring version update only on the server and not at the individual user clients 630 a , 630 b , 630 n .
  • the clients 630 a , 630 b , 630 n need no special software to access the system 600 .
  • the Server 606 assigns each captured event to a specific issue which belongs to the same tester client. Thus, if a tester 620 a generates an event, the event may only be assigned to an issue that is associated with (i.e., belongs to) tester 620 a .
  • the Server 606 copies all information on an issue to an XML file stored in the Server database 610 whenever the issue is updated. This allows the user to process the information on an issue with another application.
  • the Server 606 may be configured to track multiple issues per client.
  • issues associated with a given tester client 620 a , 620 b , 620 m are stored in one or more corresponding XML file(s) 640 a 1 , . . . , 640 a i , 640 b 1 , . . . , 640 b j , 640 m 1 , . . . , 640 m k in the Server event store 610 .
  • the Server 606 keeps track of a list of pending events for each issue and client. Because issues are set up and recorded manually through the Web GUI by a technician, the system may generate an event before the technician has create an issue for it. For example, a Diagnostic Failure may be generated by a tester 620 a and sent to the system 600 prior to the technician setting up an issue associated with the Diagnostic Failure event. In this case, this Diagnostic Failure event, like all unassigned events, are stored in a temporary “default issue” file 644 a , 644 b , 644 m associated with the particular tester 620 a , 620 b , 620 m until it can be reassigned by the technician/client. Events stored to a default issue file 644 a , 644 b , 644 m are considered “pending”.
  • the Server 606 assigns a unique ID to each event that is successfully stored in the Server 606 .
  • the Server 606 may include additional utilities that allow event tracking and reporting.
  • a report generator 655 generates a summary XML file once per pre-determined interval (e.g., once per month) and stores the summary XML report on the server.
  • the user can also access the server reporting utilities to run a report and output the results to an XML file.
  • one reporting feature of the Web GUI 608 may be a web page that lists all issues that are stored in a Server 606 that have not been closed (i.e., resolved). Another report may provide the user with an XML issue file that can be downloaded and opened using another application for processing.
  • FIG. 7 illustrates the functional logic operation of an exemplary embodiment of the Web GUI 608 .
  • Presentation Logic 748 is implemented by the Web GUI 608 running on the Server 606 ( FIG. 6 ).
  • the Presentation Logic 748 includes a Web Page generator 704 which generates and presents an Event Screen 702 on a user's display. In doing so, the Presentation Logic 748 utilizes graphical presentation values associated with events from a selected tester as defined and stored in the Tester Configuration File 740 corresponding to the tester of interest to generate the graphics on the user's screen.
  • the Presentation Logic 748 presents the stored event attribute values 708 stored in the event store 610 for events corresponding to the test cell of interest.
  • the Event Screen 702 includes a mechanism to allow a user to store new event attribute values 706 , for example using a listener 746 implemented in the Web GUI logic 608 on the server 606 ( FIG. 6 ) which detects user input to store new event attribute values.
  • the Web GUI logic stores 706 new event attribute values in the event store 610 upon user input of new event attribute values.
  • FIG. 8 illustrates an exemplary embodiment of an Event Summary Screen 800 presented by the Presentation Logic 748 ( FIG. 7 ) of the Web GUI 608 of the Event Log Management Software.
  • the Event Summary Screen 800 displays an event summary comprising a list of events for a particular tester.
  • the events in the Event Summary Screen 800 are associated with a particular tester, it will be appreciated that an event summary could be presented displaying events associated with a given location (e.g., site, system, module, quadrant, sub-quadrant, etc.).
  • a given location e.g., site, system, module, quadrant, sub-quadrant, etc.
  • the Events Summary Screen 800 displays the events in tabular form, including an event ID 802 , the event type 804 , whether the event was entered manually or automatically 806 , a description of the event 808 , the date/time of event creation 810 , and date/time of the last modification to the event 812 .
  • Each event in the Events Summary Screen 800 is selectable to display details of the event.
  • FIG. 9 illustrates an exemplary embodiment of an Event Detail Screen 900 presented by the Presentation Logic 748 ( FIG. 7 ) of the Web GUI 608 of the Event Log Management Software, illustrating the detail of an event selected from the Event Summary Screen 800 .
  • the selected event is of type “Diagnostic Failure”.
  • the Event Detail Screen 900 displays the event information in detail, including an event ID 902 , the event type 904 , whether the event was entered manually or automatically 906 , a description of the event 908 , the date/time of event creation 910 , and date/time of the last modification to the event 912 .
  • the event detail attributes associated with a Diagnostic Failure event type are also displayed in the Event Detail Screen 900 , corresponding to the TestCell.xml configuration file from above.
  • the Diagnostic Failure event attributes therefore displayed include the Diagnostic Number 914 , the Failure Text 916 , the Failure Condition 918 , Notes 920 , the Employee 922 , a comboBox 924 entitled “Found During” with possible option values including “N/A”, “Installation”, “PM”, “Power Up”, “Probing”, “Troubleshooting”, “Retrofit”, “Engineering”, and “Automation improvements”, the Software Revision 926 , a comboBox 928 entitled “Slot Location” with possible option values including “N/A”, “QA”, “QB”, “QC”, “QD”, “AC1”, “AC2”, “AC3”, etc., the Serial Number 930 , a comboBox 932 entitled “Part Description” with option values including “AC Cal Board”, “AC/DC”, “ACPS/PDU”, “Auxiliary Power Supply
  • the architecture of the Event Log Management System provides hardware independent automatic event capture, storage, and tracking, and a hardware independent GUI that allows user access with only a Web browser. Events are encapsulated in issues to allow symptoms (i.e., events) to be associated directly with the overall perception of what is happening (i.e., an issue), thereby displaying tracked events in a user-understandable format to assist the user in pinpointing and tracking sources of problems, areas of high activity, etc.
  • the innovative server architecture allows the addition, and modification, of any entry in the list of test cells, equipment, or modules monitored at any time during the life of the system. Not only can new entries be added by merely adding a corresponding configuration file to the server database, but also the attributes describing these entries can be variable since XML supports storing variable attribute lists.

Abstract

The present invention is an event log management system and method for monitoring the reliability of test systems. An event log management system includes a data store which stores at least one tester configuration file, a hardware independent event capture function which captures events from at least one monitored tester associated with one of the at least one test configuration files, a graphical user interface which receives issue information from a user, and a server which manages storage and tracking of the captured events.

Description

    BACKGROUND OF THE INVENTION
  • The present invention relates generally to test system reliability monitoring, and more particularly to systems and methods for application specific event log management.
  • Modern semiconductor manufacturing facilities utilize Automated Test Equipment (ATE) for testing integrated circuit devices. ATE allows automated testing of integrated circuits and is therefore of paramount importance for achieving reliable high volume manufacturing of such devices. ATE may be linked to a wafer prober to test semiconductor wafers prior to dicing and packaging into individual integrated circuit devices. ATE may also be linked to a device handler to test packaged devices. The combination of ATE with a wafer prober and/or device handler is often referred to as a test cell.
  • The test cell is the cornerstone in the implementation of a semiconductor manufacturer's test strategy for a manufacturing facility. During high volume integrated circuit manufacturing, the failure of a test cell can lead to loss of significant revenue if not addressed expediently. Of course, it is always preferable and more cost effective to actively prevent test cell failures prior to their occurrence rather than to diagnose and repair the test cell after a failure occurs.
  • Therefore, system reliability monitoring, prediction and improvement based on measured data acquired in the target test cell(s) is of great interest to semiconductor manufacturers.
  • One of the difficulties with monitoring reliability of a distributed fleet of test cells is the process of gathering the information. Currently, most acquisition of data relating to the reliability of a test cell is manual, taking the form of a technician observing the test cell behavior, recording specific results, and centralizing the data in a manner that can be easily summarized for a floor manager. This process is inefficient, and can lead to incomplete or error-prone data.
  • An improvement over the above technique is the use of software implemented to facilitate the gathering and reporting aspects of the process. While certainly an improvement over the manual process, it still suffers from potential data entry error by the technician. Oftentimes the test cell data can be esoteric and cumbersome to verify its correctness before being entered. Such examples are serial numbers and diagnostic measurements.
  • The monitoring of test cell reliability and the problems associated therewith applies generally to all test equipment, especially automated test equipment, or hereinafter simply “testers”, that are distributed in a high-volume manufacturing facility.
  • It would therefore be desirable to have a system that identifies, acquires, stores, analyzes, and reports fundamental test cell data that will enable the monitoring and improvement of the test cell reliability, thereby helping to maximize the time that the test cell is operating properly.
  • SUMMARY OF THE INVENTION
  • Embodiments of the invention include methods and apparatus for monitoring tester reliability.
  • In one embodiment, an event log management system comprises a data store which stores at least one tester configuration file, a hardware independent event capture function which captures events from at least one monitored tester, each associated with a corresponding test configuration file, a graphical user interface which receives issue information from a user, and a server which receives the issue information from the graphical user interface and creates an issue data element corresponding to the issue information, and which receives the captured events from the event capture function and stores the captured events in an event store, associating respective captured events with corresponding respective issues.
  • In one embodiment, a method for managing events of at least one tester comprises obtaining at least one tester configuration file, automatically capturing events from at least one monitored tester associated with one of the at least one test configuration files using a hardware independent interface, receiving issue information, and providing a server which creates an issue data element corresponding to the issue information, and which stores the captured events in an event store, and associates respective captured events with corresponding respective issues.
  • In one embodiment, an Event Log Management System comprises a data store which stores at least one tester configuration file, each tester configuration file implemented in XML and comprising one or more event type definitions and corresponding attribute definitions, a hardware independent event capture function which captures events from at least one monitored tester associated with one of the at least one test configuration files, a Web enabled graphical user interface which receives issue information associated with a user perceived condition from a user, and a server which creates an issue file implemented in XML corresponding to and encapsulating the issue information, and which encapsulates captured events captured by the hardware independent event capture function in respective issue files corresponding to respective issues to which the respective captured events are associated.
  • BRIEF DESCRIPTION OF THE DRAWINGS
  • A more complete appreciation of this invention, and many of the attendant advantages thereof, will be readily apparent as the same becomes better understood by reference to the following detailed description when considered in conjunction with the accompanying drawings in which like reference symbols indicate the same or similar components, wherein:
  • FIG. 1 is a block diagram illustrating networked use of an Event Log Management System;
  • FIG. 2 is a block diagram illustrating an exemplary embodiment of an Event Log Management System;
  • FIG. 3 is a diagram of an event;
  • FIG. 4 is a diagram of an issue;
  • FIG. 5 is a perspective view of a tester that may be monitored by the Event Log Management System;
  • FIG. 6 is a functional block diagram illustrating the functional logic of an exemplary embodiment of event log management software;
  • FIG. 7 is a functional block diagram illustrating the functional logic operation of an exemplary embodiment of a Web GUI;
  • FIG. 8 is a screen shot of an exemplary embodiment of an event summary report presented by the Web GUI of the Event Log Management System; and
  • FIG. 9 is a screen shot of an exemplary embodiment of an event detail report presented by the Web GUI of the Event Log Management System.
  • DETAILED DESCRIPTION
  • In the following detailed description of the embodiments, reference is made to the accompanying drawings which form a part hereof, and in which is shown by way of illustration specific embodiments in which the invention may be practiced. These embodiments are described in sufficient detail to enable those skilled in the art to practice the invention, and it is to be understood that other embodiments may be utilized and that structural logical and electrical changes may be made without departing from the spirit and scope of the present inventions. The following detailed description is, therefore, not to be taken in a limiting sense, and the scope of the present inventions is defined only by the appended claims.
  • Embodiments of the invention presented herein describe systems and methods to identify, acquire, store, analyze, and report fundamental test cell data that enables the monitoring and improvement of the tester reliability, thereby helping to maximize the time the test cell is up and running normally.
  • FIG. 1 is a block diagram illustrating the use of an Event Log Management System 100 a monitoring a number of testers 120 a, 120 b, 120 c, 120 d, 120 e, 120 f. Testers 120 a, 120 b, 120 c are located at site 110 a, while testers 120 d, 120 e, 120 f are located at site 110 b. A number of users 130 a, 130 b, 130 c may connect to the Event Log Management System 100 a via a web browser to interact with the system 100 a.
  • A site may be physical or logical. For example, a site may be a physical geographical location, and/or a site may be a logical distributed fleet of testers under common business control. One or more additional Event Log Management Systems 100 b may monitor another number of testers 120 g, 120 h, 120 i, which may or may not be located at a number of different respective sites 110 c. A number of users 130 d, 130 e may connect to the Event Log Management System 100 b via a web browser to interact with the system 100 b.
  • FIG. 2 is a block diagram illustrating an exemplary embodiment of an Event Log Management System 200 that may implement the Event Log Management System(s) 100 a, 100 b of FIG. 1. As illustrated, the system 200 includes an Event Capture module 202, an Application Program Interface (API) module 204, a Server module 206, a Web GUI module 208, and an event store 210. One or more testers 220 a, 220 b, 200 m are monitored by the system 200. The testers 220 a, 220 b, 200 m generate events that reflect the operating state of one or more components of the respective testers 220 a, 220 b, 200 m. The Event Log Management System 200 captures, indexes, and stored the captured events in the event store 210. Users 230 a, 230 b, 230 n may request various reports relating to the stored events and may enter event data manually.
  • An event is a specific occurrence of an operating state of a given tester as defined in a tester configuration file corresponding to the tester. Events may be captured automatically through the use of the event capture module 202. Events may also be entered into the system manually by a user through the Web GUI 208.
  • FIG. 3 illustrates an exemplary test system event 300 diagrammatically. In this embodiment, each test system event 300 comprises a date and time stamp 310, a system ID 320 (for example, a hostname), an event type 330, and a location 340. An event may include additional attributes (not shown) depending on the value of the event type.
  • The possible event types and corresponding attributes may vary from application to application, and are configurable by way of a tester configuration file, which in an exemplary embodiment is implemented as an XML file. For example, in an exemplary embodiment, the event type 230 of a given event may be one the following types:
    Diagnostic failure: A diagnostic test failed. Diagnostic information ssuch as the test number, description,
    test value and limit information may be provided in event attribute fields
    Calibration failure: A calibration (for example, a Programmable Power Supply (PPS), Pin Electronics (direct
    current) (PE DC), Pin Electronics (alternating current) (PE AC), Algorithm Pattern Generator (APG) etc.) failed
    on the given piece of hardware
    Application Failure: An application (for example, a customer's software to run a particular test) failed on
    the given piece of hardware
    Machanical Failure: A piece of hardware failed.
    Figure US20070260932A1-20071108-C00001
  • In an exemplary embodiment, the event location 240 may be one of likewaterleaks dockingproblems,and the following:
      • the whole system
      • a system quadrant
      • a sub-quadrant
      • a site
      • a module within a site 0 c
  • For example, referring to FIG. 1, a site 110 a, 110 b, 110 c (perhaps corresponding to a particular geographical location) is a set of systems. A system might be a particular tester 120 a, . . . , 120 i, such as a test cell. A system may comprise a plurality of modules such as PPS, PE, APG, etc. A module may comprise several sub-modules (for example, four quadrants in the PE module). Sub-modules may be further sectioned (for example, into sub-quadrants).
  • Issues are a higher level abstraction of one or more events. Essentially, an issue describes what the actual problem was, rather than its collective symptoms (which are the events). In other words, issues encapsulate events. As an example, suppose a given tester generates a diagnostic failure event, a configuration change event (from swapping boards to see if the failure will follow the board), and then another diagnostic failure. These events may all relate to the same issue, which may be, for example, that the site module is defective and needs to be replaced. Thus, the issue is what the technician sees and works with, while the events are the low level detail that the vendor is concerned with. Issues may be entered into the system manually by a user through the Web GUI 208.
  • FIG. 4 illustrates an exemplary issue 400 diagrammatically. In this embodiment, an issue 400 comprises one or more attributes such as a date/time 410, an issue ID 420, an issue description 430, an issue location 440, and a list 450 (or pointers to) one or more events associated with the issue.
  • Server Module
  • The Server 206 manages the event store 210, which is a central storage location for storing details of events and issues.
  • The Server 206 aggregates the information from all tester and user clients that have been configured to use the Server 206. In one embodiment, a single Server 206 services all clients in operation. In another embodiment, multiple Servers 206 service subsets of the clients. For example, one Server 206 may service clients in one or more geographical locations, while another separate Server 206 may service clients in another geographical location. For example, system 100 a in FIG. 1 serves testers at sites 110 a and 110 b, while system 100 b serves testers at site 110 c. If multiple Servers 206 are used by a customer, in one embodiment, data may be exported and imported from one Server 206 to another, thereby allowing data to be aggregated into one logical Server 206 for analysis. Thus, using the above example, event and issue data may be exported from system 100 b to system 100 a, or vice versa.
  • The Server 206 also implements the functional logic that provides the user with web access to provide detailed information on new events and issues, and to edit and analyze existing issues.
  • Event Identification and Capture
  • The process of testing ICs using a tester such as an ATE test cell generates large amounts of data. Some of this data relates to the characteristics of the ICs themselves. Other parts of this data relates to the interactions between the ICs and the test cell, while another part of this data relates to the states and general operating conditions of the test cell.
  • The states through which the test cell transitions depend largely on the particular programmed sequence set up by the user. Test cell reliability depends to some extent on this test sequence. For example, some test sequences may stress the test cell more than other test sequences, leading to potentially more failures over time.
  • The Event Capture module 202 automatically adapts to any programmed test sequence and automatically captures events from monitored testers which reflect the state and operating conditions of the monitored testers at any selected time. The Event Capture module 202 comprises software code configured to receive events from monitored test devices. Events from each monitored test device may be configured differently, and is defined in a tester configuration file associated with the tester that generates the event. The Event Capture module 202 communicates with each monitored tester using a published API (as implemented in the API module 204).
  • API Module
  • The API module implements an Application Program Interface that allows an application or software component (e.g., ATE system software, a software tool or even a customer application utilizing the Event Log Management System 200) to log an event with detailed information to the Server 206.
  • The Event Log Management System utilizes a published API which defines a clear interface with which testers need to adhere to in order to store its data effectively. The advantage of publishing the API to the customers is that if a customer wishes to extend the Event Log Management System 200 to capture events and track issues for other types of devices (such as handlers, ovens, or other testers), the manufacturer of a specific device need only publish its own Event Log Management System configuration file (describing different event types and their attributes) and ensure its software adheres to the API.
  • In an exemplary embodiment, the Event Log Management System utilizes “Web Services”, a well-known universal standard that supports interoperable machine-to-machine interaction over a network. In one embodiment, Web Services Description Language (WSDL) is used in combination with Simple Object Access Protocol (SOAP) and Extensible Markup Language (XML) Schema to provide web services over the internet. WSDL describes the public interface to the web service. WSDL is an XML-based service description on how to communicate using the web service; namely, the protocol bindings and message formats required to interact with the web services listed in its directory. The supported operations and messages are described abstractly, and then bound to a concrete network protocol and message format. SOAP is a protocol for exchanging XML-based messages over a computer network, normally using HyperText Transfer Protocol (HTTP) to transfer or convey information on the World Wide Web. Web Services, WSDL, XML, and SOAP are well-known in the art and are described in detail at http://en.wikipedia.org/wiki/Web_services.
  • The API 204 also provides a mechanism for feedback that triggers the Web GUI 208 for an event so that the user can provide additional information for an event (e.g., to allow the technician to enter notes to the event).
  • The API 204 may also transparently provides a fail-back mechanism in case a Server 206 is not available (for example, due to network problems) that provides essential tracking capabilities offline. To this end, if the server 206 is unavailable, an event generating tester 220 will cache each generated event to its local data store (such as a local hard drive). Each time an event is generated, the tester first attempts to purge all “cached” events to the server 206. If the Server 206 is available, the cached events are purged to the Server 206 and the cache is emptied. If the Server 206 is unavailable, the tester 220 will continue caching events.
  • Web GUI
  • The Web GUI 208 implements a graphical user interface that allows a user to interact with the event log management system. In a preferred embodiment, the Web GUI 208 is Web-enabled to allow a user to access the system 200 using only a Web browser and a network connection. The GUI functionality is stored on the Server 206 itself, thereby eliminating the need for special software at the user clients 230 a, . . . , 230 n.
  • The Web GUI 208 serves the two main purposes of issue/event input and issue/event reporting.
  • In terms of issue/event input, the Web GUI 208 allows the user to specify (and also, to an extent, modify) additional data for issues and events that are logged to the Server 206. For example, issues are set up and entered through the GUI 208. In addition, an event often includes a Notes attribute that allows the user to enter additional notes associated with the event. Additionally, the server 206 may trigger the Web GUI 208 when it receives a new event from a monitored tester to allow the user to provide additional information on an event or assign it to an issue.
  • FIG. 5 illustrates an exemplary embodiment of a tester 500, specifically an Agilent Versatest V5500 (manufactured by Agilent Technologies, Inc. of Palo Alto, Calif.), that may be monitored by the Event Log Management System 200 of FIG. 2. As illustrated, the Versatest V5500 500 comprises test head 510 with DUT (Device under test) interface 520, a manipulator 530 for positioning test head 510, DUT board 550 which plugs into underlying DUT interface 520, support rack 540 for supplying test head 510 with electrical power, cooling water and compressed air (not shown in the Figures).
  • Test head 510 comprises tester electronics including pin electronics (PE), programmable power supplies (PPS), algorithmic pattern generators (APG) and additional analog modules. Test head 510 is configured with a number of pins, for example 4096 pins. The test head supports 36 card cages. Each card cage can contain 9 digital boards or 9 analog modules, respectively. The DUT is mounted on DUT board 550, which is connected to the I/O channels by DUT interface 520. DUT interface 520 consists of high performance coax cabling and spring contact pins (pogo pins) which establish electrical connection with DUT board 520.
  • General-purpose manipulator 530 supports and positions test head 510, providing precise and repeatable connections between test head 500 and handlers or wafer probers.
  • Support rack 540 is attached to manipulator 530 and serves as the interface between test head 510 and AC power, cooling, and compressed air.
  • The tester 500 may include a display 562, a keyboard 564, and a mouse (not shown), which may serve as the interface between the user and tester 500. Other input and output devices (not shown) may also be communicatively connected to the tester 500.
  • Test software may execute on a computer or workstation 570 to allow a user to configure and set up tests, and observe test status and test data
    Figure US20070260932A1-20071108-C00002
    Figure US20070260932A1-20071108-C00003
  • The Web GUI of the Event Logging and Reporting Software 590 displays Web pages on a user's display 562 and receives user input via the Web interface.
  • FIG. 6 is a functional block diagram illustrating the functional logic of an exemplary embodiment 600 of the event log management software 590. The software 600 includes an Event Capture module 602, an Application Program Interface (API) module 604, a Server module 606, a Web GUI module 608, and an event store 610.
  • The Server 606 includes a connection handler function 651 which establishes connections and maintains the connections between the Event Log Management System 600 and the monitored testers 620 a, 620 b, 620 m.
  • Test cells that are monitored by the system 600 each have a corresponding test configuration file. Thus, for example, if the test cell 500 of FIG. 5 corresponds to tester 620 a in FIG. 6, the tester 620 a has a corresponding tester configuration file 640 a stored in the event store 610 of FIG. 6. Each tester configuration file 640 a, . . . , 640 m is specific to its corresponding tester 620 a, . . . , 620 m. In a preferred embodiment, the tester configuration files 640 a, . . . , 640 m are implemented as XML files, storing XML data comprising three categories of information pertaining to a given test cell:
      • List of event types. Each test cell is capable of generating different types of events. Each event has its own properties and attributes. Many properties and attributes are unique to that particular type of event, which requires the Event Log Management System to distinguish between different event types.
      • List of attributes (for a particular event type). Since each event may have unique attributes or properties, the description of these attributes and properties are described. For example, the attribute name for a particular event type and the possible values for the attribute are listed.
      • Graphical representation information (for each attribute). The test cell configuration file contains graphical user interface (GUI) information that assists the presentation layer in displaying event information to the end user. For each event attribute, a configuration file specifies input field type and input field length. The input field type may be, for example, a text file, a text area, a combo box, a radio control, etc. The input field length will correspond to the input field type. For example, the input field length corresponding to an input field type comprising a text file may be the size of the text field. Similarly, the input field length corresponding to an input field type comprising a text area may be the dimensions of the text area.
  • The tester configuration files 640 a, . . . , 640 m are stored directly within the system's own database (i.e., the event store 610).
  • Below is an exemplary XML file of an example configuration file associated with the Agilent Versatest V5500 system of FIG. 5.
  • A key to the TestCell.xml file describing the contents is shown in TABLE 1.
    TABLE 1
    Element Type Description
    Event Name Name of type of event.
    textField Name Name of text attribute
    comboBox Name Name of comboBox attribute
    option value Option associated with a comboBox
    textArea Name Graphical dimensions for displaying
    text
  • The logic implementing the Web GUI 608 runs on the Server 606 and not on the client(s). Therefore, the end user needs only to have access to a web browser to access the Event Log Management System 600. By centralizing the GUI on the server, version control of the GUI is simple and universal, requiring version update only on the server and not at the individual user clients 630 a, 630 b, 630 n. The clients 630 a, 630 b, 630 n need no special software to access the system 600.
  • The Server 606 assigns each captured event to a specific issue which belongs to the same tester client. Thus, if a tester 620 a generates an event, the event may only be assigned to an issue that is associated with (i.e., belongs to) tester 620 a. The Server 606 copies all information on an issue to an XML file stored in the Server database 610 whenever the issue is updated. This allows the user to process the information on an issue with another application.
  • The Server 606 may be configured to track multiple issues per client. In one embodiment, issues associated with a given tester client 620 a, 620 b, 620 m are stored in one or more corresponding XML file(s) 640 a 1, . . . , 640 a i, 640 b 1, . . . , 640 b j, 640 m 1, . . . , 640 m k in the Server event store 610.
  • The Server 606 keeps track of a list of pending events for each issue and client. Because issues are set up and recorded manually through the Web GUI by a technician, the system may generate an event before the technician has create an issue for it. For example, a Diagnostic Failure may be generated by a tester 620 a and sent to the system 600 prior to the technician setting up an issue associated with the Diagnostic Failure event. In this case, this Diagnostic Failure event, like all unassigned events, are stored in a temporary “default issue” file 644 a, 644 b, 644 m associated with the particular tester 620 a, 620 b, 620 m until it can be reassigned by the technician/client. Events stored to a default issue file 644 a, 644 b, 644 m are considered “pending”.
  • The Server 606 assigns a unique ID to each event that is successfully stored in the Server 606.
  • The Server 606 may include additional utilities that allow event tracking and reporting. For example, in one embodiment, a report generator 655 generates a summary XML file once per pre-determined interval (e.g., once per month) and stores the summary XML report on the server. Below is an example of a monthly report for an Agilent Versatest V5500 tester named “Thundercracker”:
    Thundercracker.3-2006.xml
    <?xml version=“1.0” standalone=“yes”?>
    <!-- FILTERS USED
    .name IN (v5x00)
    .name IN (Thundercracker)
    -->
    <rtsreport timeStamp=“2006/03/29 13:22:52”>
    <company name=“Agilent Technologies”>
    <site name=“Santa Clara”>
    <toolType name=“v5x00”>
    <tool name=“Thundercracker” testCellSerial=“11111111”>
    <event id=“932AF1B97F000001002DBFC16CDD1860”>
    <type>Diagnostic Failure</type>
    <created>2005/09/26 12:01:33</created>
    <modified>2005/10/25 12:37:16</modified>
    <automatic>true</automatic>
    <description>sdsdsd</description>
    <properties>
    <property key=“Diagnostic Number”></property>
    <property key=“Employee”></property>
    <property key=“Failure Condition”></property>
    <property key=“Failure Text”></property>
    <property key=“Found During”>N/A</property>
    <property key=“Notes”>this is a test</property>
    <property key=“Part Number”></property>
    <property key=“Repair Time”></property>
    <property key=“Serial Number”></property>
    <property key=“Software Revision”></property>
    </properties>
    </event>
    </tool>
    </toolType>
    </site>
    </company>
    </rtsreport>
  • Through the Web GUI 608 the user can also access the server reporting utilities to run a report and output the results to an XML file.
  • In terms of event reporting capabilities on the data stored in the Server 606, one reporting feature of the Web GUI 608 may be a web page that lists all issues that are stored in a Server 606 that have not been closed (i.e., resolved). Another report may provide the user with an XML issue file that can be downloaded and opened using another application for processing.
  • FIG. 7 illustrates the functional logic operation of an exemplary embodiment of the Web GUI 608. Presentation Logic 748 is implemented by the Web GUI 608 running on the Server 606 (FIG. 6). The Presentation Logic 748 includes a Web Page generator 704 which generates and presents an Event Screen 702 on a user's display. In doing so, the Presentation Logic 748 utilizes graphical presentation values associated with events from a selected tester as defined and stored in the Tester Configuration File 740 corresponding to the tester of interest to generate the graphics on the user's screen. The Presentation Logic 748 presents the stored event attribute values 708 stored in the event store 610 for events corresponding to the test cell of interest. The Event Screen 702 includes a mechanism to allow a user to store new event attribute values 706, for example using a listener 746 implemented in the Web GUI logic 608 on the server 606 (FIG. 6) which detects user input to store new event attribute values. The Web GUI logic stores 706 new event attribute values in the event store 610 upon user input of new event attribute values.
  • FIG. 8 illustrates an exemplary embodiment of an Event Summary Screen 800 presented by the Presentation Logic 748 (FIG. 7) of the Web GUI 608 of the Event Log Management Software. As shown, the Event Summary Screen 800 displays an event summary comprising a list of events for a particular tester. Although the events in the Event Summary Screen 800 are associated with a particular tester, it will be appreciated that an event summary could be presented displaying events associated with a given location (e.g., site, system, module, quadrant, sub-quadrant, etc.). In the exemplary embodiment shown in FIG. 8, the Events Summary Screen 800 displays the events in tabular form, including an event ID 802, the event type 804, whether the event was entered manually or automatically 806, a description of the event 808, the date/time of event creation 810, and date/time of the last modification to the event 812. Each event in the Events Summary Screen 800 is selectable to display details of the event.
  • For example, FIG. 9 illustrates an exemplary embodiment of an Event Detail Screen 900 presented by the Presentation Logic 748 (FIG. 7) of the Web GUI 608 of the Event Log Management Software, illustrating the detail of an event selected from the Event Summary Screen 800. As shown, the selected event is of type “Diagnostic Failure”. As shown, the Event Detail Screen 900 displays the event information in detail, including an event ID 902, the event type 904, whether the event was entered manually or automatically 906, a description of the event 908, the date/time of event creation 910, and date/time of the last modification to the event 912. The event detail attributes associated with a Diagnostic Failure event type are also displayed in the Event Detail Screen 900, corresponding to the TestCell.xml configuration file from above. As illustrated, the Diagnostic Failure event attributes therefore displayed include the Diagnostic Number 914, the Failure Text 916, the Failure Condition 918, Notes 920, the Employee 922, a comboBox 924 entitled “Found During” with possible option values including “N/A”, “Installation”, “PM”, “Power Up”, “Probing”, “Troubleshooting”, “Retrofit”, “Engineering”, and “Automation improvements”, the Software Revision 926, a comboBox 928 entitled “Slot Location” with possible option values including “N/A”, “QA”, “QB”, “QC”, “QD”, “AC1”, “AC2”, “AC3”, etc., the Serial Number 930, a comboBox 932 entitled “Part Description” with option values including “AC Cal Board”, “AC/DC”, “ACPS/PDU”, “Auxiliary Power Supply”, “Backplane”, “Cables”, “CBB (Cable Buffer Board)”, etc., the Part Number 934, and the Repair Time 936.
  • The architecture of the Event Log Management System provides hardware independent automatic event capture, storage, and tracking, and a hardware independent GUI that allows user access with only a Web browser. Events are encapsulated in issues to allow symptoms (i.e., events) to be associated directly with the overall perception of what is happening (i.e., an issue), thereby displaying tracked events in a user-understandable format to assist the user in pinpointing and tracking sources of problems, areas of high activity, etc.
  • The innovative server architecture allows the addition, and modification, of any entry in the list of test cells, equipment, or modules monitored at any time during the life of the system. Not only can new entries be added by merely adding a corresponding configuration file to the server database, but also the attributes describing these entries can be variable since XML supports storing variable attribute lists.
  • Additionally, between the logic implementing the Web GUI runs on the system server and not on the client(s), an end user needs only to have access to a web browser and a network connection to access the Event Log Management System. By centralizing the GUI on the server, version control of the GUI is simple and universal, requiring version update only on the server and not at the individual user clients.

Claims (18)

1. An Event Log Management System, comprising:
a data store which stores at least one tester configuration file;
a hardware independent event capture function which captures events from at least one monitored tester associated with one of the at least one test configuration files;
a graphical user interface which receives issue information from a user; and
a server which receives the issue information from the graphical user interface and creates an issue data element corresponding to the issue information, and which receives the captured events from the event capture function and stores the captured events in an event store, associating respective captured events with corresponding respective issues.
2. The system of claim 1, wherein the graphical user interface is web enabled.
3. The system of claim 1, wherein the hardware independent event capture function comprises a Web Services application program interface (API).
4. The system of claim 1, wherein the at least one tester configuration file is implemented in XML.
5. The system of claim 1, further comprising a reporting function which reports events associated with a particular one of the at least one testers.
6. The system of claim 1, further comprising a reporting function which reports events associated with a particular issue.
7. The system of claim 1, wherein the issue data element created by the server is implemented as an XML file.
8. The system of claim 7, wherein when the server receives a particular captured event from the event capture function, the server determines which particular issue, if any, of the issues the particular captured event is associated with, and stores the particular captured event in the XML file comprising the issue data element associated with the particular issue, and if the particular capture event is not associated with any issue, stores the particular captured event in an XML file comprising a default issue data element that is associated with a default issue.
9. A method for managing events of at least one tester, comprising:
obtaining at least one tester configuration file;
automatically capturing events from at least one monitored tester associated with one of the at least one test configuration files using a hardware independent interface;
receiving issue information; and
providing a server which creates an issue data element corresponding to the issue information, and which stores the captured events in an event store, and associates respective captured events with corresponding respective issues.
10. The method of claim 9, wherein the step of receiving issue information is performed through a web enabled graphical user interface.
11. The method of claim 9, wherein the step of automatically capturing events from at least one monitored tester comprises receiving events from the at least one monitored tester using a hardware independent event Web Services application program interface (API).
12. The method of claim 9, further comprising:
reporting events associated with a particular one of the at least one testers into a report, formatting the events in the report according to event attributes as defined in the tester configuration file associated with the particular one of the at least one testers.
13. The method of claim 9, further comprising a reporting function which reports events associated with a particular issue into a report, formatting the events in the report according to event attributes as defined in the tester configuration file associated with the particular one of the at least one testers.
14. The method of claim 13, wherein when the server receives a particular captured event from the event capture function, determines which particular issue, if any, of the issues the particular captured event is associated with, and stores the particular captured event in an XML issue file associated with the particular issue, and if the particular capture event is not associated with any issue, stores the particular captured event in an XML default issue file associated with a default issue.
15. An Event Log Management System, comprising:
a data store which stores at least one tester configuration file, each tester configuration file implemented in XML and comprising one or more event type definitions and corresponding attribute definitions;
a hardware independent event capture function which captures events from at least one monitored tester associated with one of the at least one test configuration files;
a Web enabled graphical user interface which receives issue information associated with a user perceived condition from a user; and
a server which creates an issue file implemented in XML corresponding to and encapsulating the issue information, and which encapsulates captured events captured by the hardware independent event capture function in respective issue files corresponding to respective issues to which the respective captured events are associated.
16. The system of claim 15, wherein the hardware independent event capture function comprises a Web Services application program interface (API).
17. The system of claim 15, further comprising a reporting function which reports events associated with a particular one of the at least one testers in an XML report file.
18. The system of claim 15, further comprising a reporting function which reports events associated with a particular issue in an XML report file.
US11/402,113 2006-04-11 2006-04-11 Event log management system Abandoned US20070260932A1 (en)

Priority Applications (6)

Application Number Priority Date Filing Date Title
US11/402,113 US20070260932A1 (en) 2006-04-11 2006-04-11 Event log management system
JP2007099885A JP2007293840A (en) 2006-04-11 2007-04-05 Event log management system
SG200702619-8A SG136891A1 (en) 2006-04-11 2007-04-10 Event log management system
KR1020070035168A KR20070101163A (en) 2006-04-11 2007-04-10 Event log management system
CNA2007100794909A CN101118534A (en) 2006-04-11 2007-04-11 Event log management system
DE102007017012A DE102007017012A1 (en) 2006-04-11 2007-04-11 Event Log Management System

Applications Claiming Priority (1)

Application Number Priority Date Filing Date Title
US11/402,113 US20070260932A1 (en) 2006-04-11 2006-04-11 Event log management system

Publications (1)

Publication Number Publication Date
US20070260932A1 true US20070260932A1 (en) 2007-11-08

Family

ID=38622430

Family Applications (1)

Application Number Title Priority Date Filing Date
US11/402,113 Abandoned US20070260932A1 (en) 2006-04-11 2006-04-11 Event log management system

Country Status (6)

Country Link
US (1) US20070260932A1 (en)
JP (1) JP2007293840A (en)
KR (1) KR20070101163A (en)
CN (1) CN101118534A (en)
DE (1) DE102007017012A1 (en)
SG (1) SG136891A1 (en)

Cited By (33)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US20090198549A1 (en) * 2008-01-31 2009-08-06 Kearns James A Automated Repair System and Method for Network-Addressable Components
US20090271448A1 (en) * 2008-04-25 2009-10-29 International Business Machines Corporation System, Method, and Computer Readable Media for Identifying a User-Initiated Log File Record in a Log File
US20090292742A1 (en) * 2008-05-21 2009-11-26 International Business Machines System, Method, and Computer Readable Media for Identifying a Log File Record in a Log File
US20100005342A1 (en) * 2008-07-01 2010-01-07 Dambra Joseph J Redundant Error Detection in a Clinical Diagnostic Analyzer
WO2010036261A1 (en) * 2008-09-26 2010-04-01 Hewlett-Packard Development Company, L.P. Event management system for creating a second event
US20100091687A1 (en) * 2008-10-15 2010-04-15 Ted Beers Status of events
US20110069141A1 (en) * 2008-04-30 2011-03-24 Mitchell April S Communication Between Scheduled And In Progress Event Attendees
US20110093590A1 (en) * 2008-04-30 2011-04-21 Ted Beers Event Management System
US20110209008A1 (en) * 2010-02-25 2011-08-25 Anton Arapov Application Reporting Library
US20110307742A1 (en) * 2009-03-30 2011-12-15 Hitachi, Ltd. Method and apparatus for cause analysis involving configuration changes
WO2013095470A1 (en) * 2011-12-21 2013-06-27 Intel Corporation Error framework for a microprocessor and system
US20160127180A1 (en) * 2014-10-30 2016-05-05 Splunk Inc. Streamlining configuration of protocol-based network data capture by remote capture agents
US9453879B2 (en) 2014-12-01 2016-09-27 Apple Inc. On-die system for monitoring and predicting performance
US9519698B1 (en) 2016-01-20 2016-12-13 International Business Machines Corporation Visualization of graphical representations of log files
US9596253B2 (en) 2014-10-30 2017-03-14 Splunk Inc. Capture triggers for capturing network data
US9762443B2 (en) 2014-04-15 2017-09-12 Splunk Inc. Transformation of network data at remote capture agents
US9838512B2 (en) 2014-10-30 2017-12-05 Splunk Inc. Protocol-based capture of network data using remote capture agents
WO2018030989A1 (en) * 2016-08-08 2018-02-15 Abbott Medical Optics Inc. System and method for providing a standardized medical device control
US9923767B2 (en) 2014-04-15 2018-03-20 Splunk Inc. Dynamic configuration of remote capture agents for network data capture
US10127273B2 (en) 2014-04-15 2018-11-13 Splunk Inc. Distributed processing of network data using remote capture agents
US10289533B2 (en) * 2017-08-30 2019-05-14 Sap Se Managing extraction of data for testing
US10334085B2 (en) 2015-01-29 2019-06-25 Splunk Inc. Facilitating custom content extraction from network packets
US10360196B2 (en) 2014-04-15 2019-07-23 Splunk Inc. Grouping and managing event streams generated from captured network data
US10366101B2 (en) 2014-04-15 2019-07-30 Splunk Inc. Bidirectional linking of ephemeral event streams to creators of the ephemeral event streams
US10462004B2 (en) 2014-04-15 2019-10-29 Splunk Inc. Visualizations of statistics associated with captured network data
US10523521B2 (en) 2014-04-15 2019-12-31 Splunk Inc. Managing ephemeral event streams generated from captured network data
US10693742B2 (en) 2014-04-15 2020-06-23 Splunk Inc. Inline visualizations of metrics related to captured network data
US10700950B2 (en) 2014-04-15 2020-06-30 Splunk Inc. Adjusting network data storage based on event stream statistics
CN112115013A (en) * 2019-06-21 2020-12-22 昆山纬绩资通有限公司 Test data summarizing system and method thereof
US11086897B2 (en) 2014-04-15 2021-08-10 Splunk Inc. Linking event streams across applications of a data intake and query system
US11238981B2 (en) 2016-08-08 2022-02-01 Johnson & Johnson Surgical Vision, Inc. System and method for providing a genericized medical device architecture
US11281643B2 (en) 2014-04-15 2022-03-22 Splunk Inc. Generating event streams including aggregated values from monitored network data
US11936764B1 (en) 2022-07-14 2024-03-19 Splunk Inc. Generating event streams based on application-layer events captured by remote capture agents

Families Citing this family (4)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US8839349B2 (en) * 2011-10-18 2014-09-16 Mcafee, Inc. Integrating security policy and event management
CN105092992B (en) * 2014-04-15 2020-01-07 爱德万测试公司 Method and apparatus for vector controlled testing on ATE
US10810362B2 (en) * 2015-07-17 2020-10-20 Sap Se Page-based incident correlation for network applications
CN109542857B (en) * 2018-11-26 2021-06-29 杭州迪普科技股份有限公司 Audit log storage method, audit log query method, audit log storage device, audit log query device and related equipment

Citations (10)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US5666481A (en) * 1993-02-26 1997-09-09 Cabletron Systems, Inc. Method and apparatus for resolving faults in communications networks
US6385644B1 (en) * 1997-09-26 2002-05-07 Mci Worldcom, Inc. Multi-threaded web based user inbox for report management
US20020087680A1 (en) * 2000-08-01 2002-07-04 Cerami Richard S. Proactive service request management and measurement
US6766368B1 (en) * 2000-05-23 2004-07-20 Verizon Laboratories Inc. System and method for providing an internet-based correlation service
US6859783B2 (en) * 1995-12-29 2005-02-22 Worldcom, Inc. Integrated interface for web based customer care and trouble management
US7016902B2 (en) * 2002-04-15 2006-03-21 Microsoft Corporation Flexible subscription-based event notification
US7237023B2 (en) * 2001-03-30 2007-06-26 Tonic Software, Inc. System and method for correlating and diagnosing system component performance data
US20070174716A1 (en) * 2005-12-30 2007-07-26 Uwe Erdtmann Health check monitoring process
US7257744B2 (en) * 2003-03-17 2007-08-14 Tyco Telecommunications (Us) Inc. System and method for fault diagnosis using distributed alarm correlation
US7281170B2 (en) * 2000-05-05 2007-10-09 Computer Associates Think, Inc. Help desk systems and methods for use with communications networks

Patent Citations (11)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US5666481A (en) * 1993-02-26 1997-09-09 Cabletron Systems, Inc. Method and apparatus for resolving faults in communications networks
US6859783B2 (en) * 1995-12-29 2005-02-22 Worldcom, Inc. Integrated interface for web based customer care and trouble management
US6385644B1 (en) * 1997-09-26 2002-05-07 Mci Worldcom, Inc. Multi-threaded web based user inbox for report management
US7281170B2 (en) * 2000-05-05 2007-10-09 Computer Associates Think, Inc. Help desk systems and methods for use with communications networks
US6766368B1 (en) * 2000-05-23 2004-07-20 Verizon Laboratories Inc. System and method for providing an internet-based correlation service
US20020087680A1 (en) * 2000-08-01 2002-07-04 Cerami Richard S. Proactive service request management and measurement
US7032016B2 (en) * 2000-08-01 2006-04-18 Qwest Communications International, Inc. Proactive service request management and measurement
US7237023B2 (en) * 2001-03-30 2007-06-26 Tonic Software, Inc. System and method for correlating and diagnosing system component performance data
US7016902B2 (en) * 2002-04-15 2006-03-21 Microsoft Corporation Flexible subscription-based event notification
US7257744B2 (en) * 2003-03-17 2007-08-14 Tyco Telecommunications (Us) Inc. System and method for fault diagnosis using distributed alarm correlation
US20070174716A1 (en) * 2005-12-30 2007-07-26 Uwe Erdtmann Health check monitoring process

Cited By (72)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US20090198549A1 (en) * 2008-01-31 2009-08-06 Kearns James A Automated Repair System and Method for Network-Addressable Components
US8219582B2 (en) 2008-04-25 2012-07-10 International Business Machines Corporation System, method, and computer readable media for identifying a user-initiated log file record in a log file
US20090271448A1 (en) * 2008-04-25 2009-10-29 International Business Machines Corporation System, Method, and Computer Readable Media for Identifying a User-Initiated Log File Record in a Log File
US9075817B2 (en) * 2008-04-25 2015-07-07 International Business Machines Corporation System, method, and computer readable media for identifying a user-initiated log file record in a log file
US20140214777A1 (en) * 2008-04-25 2014-07-31 International Business Machines Corporation System, method, and computer readable media for identifying a user-initiated log file record in a log file
US8732199B2 (en) 2008-04-25 2014-05-20 International Business Machines Corporation System, method, and computer readable media for identifying a user-initiated log file record in a log file
US9535946B2 (en) 2008-04-25 2017-01-03 International Business Machines Corporation System method, and computer readable media for identifying a user-initiated log file record in a log file
US20110069141A1 (en) * 2008-04-30 2011-03-24 Mitchell April S Communication Between Scheduled And In Progress Event Attendees
US20110093590A1 (en) * 2008-04-30 2011-04-21 Ted Beers Event Management System
US8090994B2 (en) * 2008-05-21 2012-01-03 International Business Machines Corporation System, method, and computer readable media for identifying a log file record in a log file
US20090292742A1 (en) * 2008-05-21 2009-11-26 International Business Machines System, Method, and Computer Readable Media for Identifying a Log File Record in a Log File
US10002678B2 (en) * 2008-07-01 2018-06-19 Ortho-Clinical Diagnostics, Inc. Redundant error detection in a clinical diagnostic analyzer
US20160162653A1 (en) * 2008-07-01 2016-06-09 Ortho-Clinical Diagnostics, Inc. Redundant error detection in a clinical diagnostic analyzer
US20100005342A1 (en) * 2008-07-01 2010-01-07 Dambra Joseph J Redundant Error Detection in a Clinical Diagnostic Analyzer
US20110179157A1 (en) * 2008-09-26 2011-07-21 Ted Beers Event Management System For Creating A Second Event
WO2010036261A1 (en) * 2008-09-26 2010-04-01 Hewlett-Packard Development Company, L.P. Event management system for creating a second event
US20100091687A1 (en) * 2008-10-15 2010-04-15 Ted Beers Status of events
US8601319B2 (en) * 2009-03-30 2013-12-03 Hitachi, Ltd. Method and apparatus for cause analysis involving configuration changes
US9003230B2 (en) 2009-03-30 2015-04-07 Hitachi, Ltd. Method and apparatus for cause analysis involving configuration changes
US20110307742A1 (en) * 2009-03-30 2011-12-15 Hitachi, Ltd. Method and apparatus for cause analysis involving configuration changes
US8245082B2 (en) * 2010-02-25 2012-08-14 Red Hat, Inc. Application reporting library
US20110209008A1 (en) * 2010-02-25 2011-08-25 Anton Arapov Application Reporting Library
WO2013095470A1 (en) * 2011-12-21 2013-06-27 Intel Corporation Error framework for a microprocessor and system
TWI506419B (en) * 2011-12-21 2015-11-01 Intel Corp Error framework for a microprocessor and system
US9495233B2 (en) 2011-12-21 2016-11-15 Intel Corporation Error framework for a microprocesor and system
US10127273B2 (en) 2014-04-15 2018-11-13 Splunk Inc. Distributed processing of network data using remote capture agents
US11252056B2 (en) 2014-04-15 2022-02-15 Splunk Inc. Transforming event data generated by remote capture agents using user-generated code
US11863408B1 (en) 2014-04-15 2024-01-02 Splunk Inc. Generating event streams including modified network data monitored by remote capture agents
US11818018B1 (en) 2014-04-15 2023-11-14 Splunk Inc. Configuring event streams based on identified security risks
US9762443B2 (en) 2014-04-15 2017-09-12 Splunk Inc. Transformation of network data at remote capture agents
US11716248B1 (en) 2014-04-15 2023-08-01 Splunk Inc. Selective event stream data storage based on network traffic volume
US11451453B2 (en) 2014-04-15 2022-09-20 Splunk Inc. Configuring the generation of ephemeral event streams by remote capture agents
US11314737B2 (en) 2014-04-15 2022-04-26 Splunk Inc. Transforming event data using values obtained by querying a data source
US9923767B2 (en) 2014-04-15 2018-03-20 Splunk Inc. Dynamic configuration of remote capture agents for network data capture
US11296951B2 (en) 2014-04-15 2022-04-05 Splunk Inc. Interval-based generation of event streams by remote capture agents
US11281643B2 (en) 2014-04-15 2022-03-22 Splunk Inc. Generating event streams including aggregated values from monitored network data
US10693742B2 (en) 2014-04-15 2020-06-23 Splunk Inc. Inline visualizations of metrics related to captured network data
US11245581B2 (en) 2014-04-15 2022-02-08 Splunk Inc. Selective event stream data storage based on historical stream data
US10257059B2 (en) 2014-04-15 2019-04-09 Splunk Inc. Transforming event data using remote capture agents and transformation servers
US11108659B2 (en) 2014-04-15 2021-08-31 Splunk Inc. Using storage reactors to transform event data generated by remote capture agents
US11086897B2 (en) 2014-04-15 2021-08-10 Splunk Inc. Linking event streams across applications of a data intake and query system
US10951474B2 (en) 2014-04-15 2021-03-16 Splunk Inc. Configuring event stream generation in cloud-based computing environments
US10348583B2 (en) 2014-04-15 2019-07-09 Splunk Inc. Generating and transforming timestamped event data at a remote capture agent
US10360196B2 (en) 2014-04-15 2019-07-23 Splunk Inc. Grouping and managing event streams generated from captured network data
US10366101B2 (en) 2014-04-15 2019-07-30 Splunk Inc. Bidirectional linking of ephemeral event streams to creators of the ephemeral event streams
US10374883B2 (en) 2014-04-15 2019-08-06 Splunk Inc. Application-based configuration of network data capture by remote capture agents
US10700950B2 (en) 2014-04-15 2020-06-30 Splunk Inc. Adjusting network data storage based on event stream statistics
US10462004B2 (en) 2014-04-15 2019-10-29 Splunk Inc. Visualizations of statistics associated with captured network data
US10523521B2 (en) 2014-04-15 2019-12-31 Splunk Inc. Managing ephemeral event streams generated from captured network data
US10193916B2 (en) 2014-10-30 2019-01-29 Splunk Inc. Configuring the generation of event data based on a triggering search query
US20160127180A1 (en) * 2014-10-30 2016-05-05 Splunk Inc. Streamlining configuration of protocol-based network data capture by remote capture agents
US10701191B2 (en) 2014-10-30 2020-06-30 Splunk Inc. Configuring rules for filtering events to be included in event streams
US10805438B2 (en) 2014-10-30 2020-10-13 Splunk Inc. Configuring the protocol-based generation of event streams by remote capture agents
US10812514B2 (en) 2014-10-30 2020-10-20 Splunk Inc. Configuring the generation of additional time-series event data by remote capture agents
US9596253B2 (en) 2014-10-30 2017-03-14 Splunk Inc. Capture triggers for capturing network data
US9843598B2 (en) 2014-10-30 2017-12-12 Splunk Inc. Capture triggers for capturing network data
US11425229B2 (en) 2014-10-30 2022-08-23 Splunk Inc. Generating event streams from encrypted network traffic monitored by remote capture agents
US10264106B2 (en) 2014-10-30 2019-04-16 Splunk Inc. Configuring generation of multiple event streams from a packet flow
US10382599B2 (en) 2014-10-30 2019-08-13 Splunk Inc. Configuring generation of event streams by remote capture agents
US9838512B2 (en) 2014-10-30 2017-12-05 Splunk Inc. Protocol-based capture of network data using remote capture agents
US9453879B2 (en) 2014-12-01 2016-09-27 Apple Inc. On-die system for monitoring and predicting performance
US11115505B2 (en) 2015-01-29 2021-09-07 Splunk Inc. Facilitating custom content extraction rule configuration for remote capture agents
US10334085B2 (en) 2015-01-29 2019-06-25 Splunk Inc. Facilitating custom content extraction from network packets
US9519698B1 (en) 2016-01-20 2016-12-13 International Business Machines Corporation Visualization of graphical representations of log files
US9684707B1 (en) 2016-01-20 2017-06-20 International Business Machines Corporation Visualization of graphical representations of log files
US9984148B2 (en) 2016-01-20 2018-05-29 International Business Machines Corporation Visualization of graphical representation of log files
US11238981B2 (en) 2016-08-08 2022-02-01 Johnson & Johnson Surgical Vision, Inc. System and method for providing a genericized medical device architecture
WO2018030989A1 (en) * 2016-08-08 2018-02-15 Abbott Medical Optics Inc. System and method for providing a standardized medical device control
US10289533B2 (en) * 2017-08-30 2019-05-14 Sap Se Managing extraction of data for testing
US11120037B2 (en) * 2019-06-21 2021-09-14 Wistron Corporation Test data integration system and method thereof
CN112115013A (en) * 2019-06-21 2020-12-22 昆山纬绩资通有限公司 Test data summarizing system and method thereof
US11936764B1 (en) 2022-07-14 2024-03-19 Splunk Inc. Generating event streams based on application-layer events captured by remote capture agents

Also Published As

Publication number Publication date
KR20070101163A (en) 2007-10-16
DE102007017012A1 (en) 2007-11-29
CN101118534A (en) 2008-02-06
JP2007293840A (en) 2007-11-08
SG136891A1 (en) 2007-11-29

Similar Documents

Publication Publication Date Title
US20070260932A1 (en) Event log management system
EP2076784B1 (en) Automated test and characterization data analysis methods and arrangement
US7644312B2 (en) Virtual machine monitoring for application operation diagnostics
US7321885B2 (en) Product framework for managing test systems, supporting customer relationships management and protecting intellectual knowledge in a manufacturing testing environment
US8381184B2 (en) Dynamic test coverage
US6314379B1 (en) Integrated defect yield management and query system
JP2010508649A6 (en) Methods and configurations for automated testing and characterization data analysis
CN106407059A (en) Server node testing system and method
CN104335056A (en) Interposer between a tester and material handling equipment to separate and control different requests of multiple entities in a test cell operation
US8005638B1 (en) Distributed test system and method
US8855801B2 (en) Automated integration of feedback from field failure to order configurator for dynamic optimization of manufacturing test processes
US7956737B2 (en) Method and apparatus for network service assurance
CN111639413B (en) Satellite automatic test system and method
CN107621988A (en) Delayed in a kind of DC test machine Fault Locating Method and system
CN111865652A (en) Public network wireless communication channel fault diagnosis method, computer equipment and storage medium
US20050097548A1 (en) Systems and methods for developing and distributing software components
US7401275B1 (en) Automated test and characterization web services
Bauer et al. The 5ESS switching system: System test, first-office application, and early field experience
Bogen et al. Handling of QoS characteristics
CN114676046A (en) Management system and method for multiple test terminals
US20130145026A1 (en) Signal manager
Popovic et al. Automated fault analysis: From requirements to implementation
CN116308414A (en) Method and device for determining the production quality of a relay protection device
CN109862066A (en) A kind of general metering original record method for uploading of QMap serializing label
US6970797B2 (en) Method and product for processing system test data

Legal Events

Date Code Title Description
AS Assignment

Owner name: AGILENT TECHNOLOGIES INC, COLORADO

Free format text: ASSIGNMENT OF ASSIGNORS INTEREST;ASSIGNORS:PRICHARD, RYAN;ROGEL-FAVLLA, BEN;REEL/FRAME:018706/0819;SIGNING DATES FROM 20060405 TO 20060406

AS Assignment

Owner name: VERIGY (SINGAPORE) PTE. LTD., SINGAPORE

Free format text: ASSIGNMENT OF ASSIGNORS INTEREST;ASSIGNOR:AGILENT TECHNOLOGIES, INC.;REEL/FRAME:019015/0119

Effective date: 20070306

Owner name: VERIGY (SINGAPORE) PTE. LTD.,SINGAPORE

Free format text: ASSIGNMENT OF ASSIGNORS INTEREST;ASSIGNOR:AGILENT TECHNOLOGIES, INC.;REEL/FRAME:019015/0119

Effective date: 20070306

STCB Information on status: application discontinuation

Free format text: ABANDONED -- FAILURE TO RESPOND TO AN OFFICE ACTION