US20060167947A1 - Communications interface database for electronic diagnostic apparatus - Google Patents
Communications interface database for electronic diagnostic apparatus Download PDFInfo
- Publication number
- US20060167947A1 US20060167947A1 US10/617,901 US61790103A US2006167947A1 US 20060167947 A1 US20060167947 A1 US 20060167947A1 US 61790103 A US61790103 A US 61790103A US 2006167947 A1 US2006167947 A1 US 2006167947A1
- Authority
- US
- United States
- Prior art keywords
- field
- attribute
- data
- record
- equipment
- 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
Links
- 238000004891 communication Methods 0.000 title claims abstract description 69
- 238000005259 measurement Methods 0.000 claims abstract description 32
- 238000000034 method Methods 0.000 claims description 55
- 238000006243 chemical reaction Methods 0.000 claims description 34
- 230000008569 process Effects 0.000 claims description 25
- 238000013500 data storage Methods 0.000 claims description 22
- 238000004519 manufacturing process Methods 0.000 claims description 15
- 239000004065 semiconductor Substances 0.000 claims description 14
- 230000004044 response Effects 0.000 claims description 7
- 238000012544 monitoring process Methods 0.000 claims description 4
- 150000001875 compounds Chemical class 0.000 description 11
- 238000003860 storage Methods 0.000 description 7
- 238000012360 testing method Methods 0.000 description 7
- 238000012546 transfer Methods 0.000 description 7
- 238000013480 data collection Methods 0.000 description 6
- 238000010586 diagram Methods 0.000 description 5
- 238000012423 maintenance Methods 0.000 description 4
- 238000010606 normalization Methods 0.000 description 4
- 235000012431 wafers Nutrition 0.000 description 4
- 230000008901 benefit Effects 0.000 description 2
- 230000008859 change Effects 0.000 description 2
- 238000005229 chemical vapour deposition Methods 0.000 description 2
- 238000010438 heat treatment Methods 0.000 description 2
- 239000000463 material Substances 0.000 description 2
- 238000009530 blood pressure measurement Methods 0.000 description 1
- 238000009529 body temperature measurement Methods 0.000 description 1
- 238000004590 computer program Methods 0.000 description 1
- 239000007943 implant Substances 0.000 description 1
- 230000006872 improvement Effects 0.000 description 1
- 238000007726 management method Methods 0.000 description 1
- NJPPVKZQTLUDBO-UHFFFAOYSA-N novaluron Chemical compound C1=C(Cl)C(OC(F)(F)C(OC(F)(F)F)F)=CC=C1NC(=O)NC(=O)C1=C(F)C=CC=C1F NJPPVKZQTLUDBO-UHFFFAOYSA-N 0.000 description 1
- 230000003287 optical effect Effects 0.000 description 1
- 238000005268 plasma chemical vapour deposition Methods 0.000 description 1
- 238000012545 processing Methods 0.000 description 1
- 230000008672 reprogramming Effects 0.000 description 1
- 238000007619 statistical method Methods 0.000 description 1
- 230000002123 temporal effect Effects 0.000 description 1
- 238000002207 thermal evaporation Methods 0.000 description 1
Images
Classifications
-
- G—PHYSICS
- G05—CONTROLLING; REGULATING
- G05B—CONTROL OR REGULATING SYSTEMS IN GENERAL; FUNCTIONAL ELEMENTS OF SUCH SYSTEMS; MONITORING OR TESTING ARRANGEMENTS FOR SUCH SYSTEMS OR ELEMENTS
- G05B19/00—Programme-control systems
- G05B19/02—Programme-control systems electric
- G05B19/418—Total factory control, i.e. centrally controlling a plurality of machines, e.g. direct or distributed numerical control [DNC], flexible manufacturing systems [FMS], integrated manufacturing systems [IMS], computer integrated manufacturing [CIM]
- G05B19/4183—Total factory control, i.e. centrally controlling a plurality of machines, e.g. direct or distributed numerical control [DNC], flexible manufacturing systems [FMS], integrated manufacturing systems [IMS], computer integrated manufacturing [CIM] characterised by data acquisition, e.g. workpiece identification
-
- G—PHYSICS
- G05—CONTROLLING; REGULATING
- G05B—CONTROL OR REGULATING SYSTEMS IN GENERAL; FUNCTIONAL ELEMENTS OF SUCH SYSTEMS; MONITORING OR TESTING ARRANGEMENTS FOR SUCH SYSTEMS OR ELEMENTS
- G05B19/00—Programme-control systems
- G05B19/02—Programme-control systems electric
- G05B19/418—Total factory control, i.e. centrally controlling a plurality of machines, e.g. direct or distributed numerical control [DNC], flexible manufacturing systems [FMS], integrated manufacturing systems [IMS], computer integrated manufacturing [CIM]
-
- G—PHYSICS
- G05—CONTROLLING; REGULATING
- G05B—CONTROL OR REGULATING SYSTEMS IN GENERAL; FUNCTIONAL ELEMENTS OF SUCH SYSTEMS; MONITORING OR TESTING ARRANGEMENTS FOR SUCH SYSTEMS OR ELEMENTS
- G05B2219/00—Program-control systems
- G05B2219/30—Nc systems
- G05B2219/31—From computer integrated manufacturing till monitoring
- G05B2219/31323—Database for CIM
-
- Y—GENERAL TAGGING OF NEW TECHNOLOGICAL DEVELOPMENTS; GENERAL TAGGING OF CROSS-SECTIONAL TECHNOLOGIES SPANNING OVER SEVERAL SECTIONS OF THE IPC; TECHNICAL SUBJECTS COVERED BY FORMER USPC CROSS-REFERENCE ART COLLECTIONS [XRACs] AND DIGESTS
- Y02—TECHNOLOGIES OR APPLICATIONS FOR MITIGATION OR ADAPTATION AGAINST CLIMATE CHANGE
- Y02P—CLIMATE CHANGE MITIGATION TECHNOLOGIES IN THE PRODUCTION OR PROCESSING OF GOODS
- Y02P90/00—Enabling technologies with a potential contribution to greenhouse gas [GHG] emissions mitigation
- Y02P90/02—Total factory control, e.g. smart factories, flexible manufacturing systems [FMS] or integrated manufacturing systems [IMS]
-
- Y—GENERAL TAGGING OF NEW TECHNOLOGICAL DEVELOPMENTS; GENERAL TAGGING OF CROSS-SECTIONAL TECHNOLOGIES SPANNING OVER SEVERAL SECTIONS OF THE IPC; TECHNICAL SUBJECTS COVERED BY FORMER USPC CROSS-REFERENCE ART COLLECTIONS [XRACs] AND DIGESTS
- Y02—TECHNOLOGIES OR APPLICATIONS FOR MITIGATION OR ADAPTATION AGAINST CLIMATE CHANGE
- Y02P—CLIMATE CHANGE MITIGATION TECHNOLOGIES IN THE PRODUCTION OR PROCESSING OF GOODS
- Y02P90/00—Enabling technologies with a potential contribution to greenhouse gas [GHG] emissions mitigation
- Y02P90/80—Management or planning
Landscapes
- Engineering & Computer Science (AREA)
- General Engineering & Computer Science (AREA)
- Manufacturing & Machinery (AREA)
- Quality & Reliability (AREA)
- Physics & Mathematics (AREA)
- General Physics & Mathematics (AREA)
- Automation & Control Theory (AREA)
- Testing And Monitoring For Control Systems (AREA)
- Testing Or Measuring Of Semiconductors Or The Like (AREA)
- Computer And Data Communications (AREA)
Abstract
A diagnostic instrument or data acquisition apparatus having a database for storing communications interface specifications and other properties of diagnostic attributes (e.g., sensor measurements or operating conditions) outputted by various classes (models or versions) of equipment to be tested. The database records include a first field identifying a class of equipment, a second field identifying (e.g., by name or description) a diagnostic attribute whose value is outputted by that class of equipment, and a third field. The third field can specify an ID (e.g., physical signal line, physical address, or logical address) that enables a diagnostic apparatus to retrieve the value of the attribute identified by the second field from the class of UUT equipment identified by the first field of the record. Alternatively, the third field can identify the communications interface at which the diagnostic attribute is transmitted.
Description
- This patent application claims the benefit under 35 USC 119(e) of U.S. provisional application No. 60/451,301 filed Mar. 1, 2003.
- The invention relates generally to electronic diagnostic or data acquisition apparatus. More specifically, the invention is an improvement to such diagnostic apparatus comprising database methods and apparatus for tabulating various models or classes of equipment (“unit under test” or “UUT”) that can be tested and, for each such class of UUT equipment, tabulating: (1) each diagnostic attribute whose value can be transmitted by that UUT; and (2) the ID (e.g., physical signal line, physical address, or logical address) and other communications interface parameters required for a diagnostic apparatus to retrieve the value of that attribute from that UUT.
- Diagnostic apparatus, also called data acquisition or data collection apparatus, is commonly used to test and troubleshoot various types of electronic equipment. The diagnostic apparatus monitors the values of electrical data generated by the electronic equipment under test (“unit under test” or “UUT”). This data generally represents various sensor measurements and/or operating conditions of the UUT, all of which are collectively referred to as “diagnostic attributes,” “collectible attributes,” or simply “attributes” of the UUT. Maintenance personnel analyze the attribute data to troubleshoot or optimize the performance of the UUT.
- Maintenance personnel typically are assigned to test and troubleshoot a variety of types of such electronic equipment. Different types and models of UUT equipment generally impose different interface requirements for connection to a diagnostic apparatus, because they differ from each other regarding the number and kind of data communications interfaces, the attributes they output at the data interfaces, and the ID's (physical signal line, physical address, or logical address) required for a diagnostic apparatus to retrieve the values of selected attributes from the UUT. In fact, different interface requirements may even exist among different production versions of the same model of equipment.
- Some conventional diagnostic apparatuses are adapted to interface with only a narrow range of UUT equipment models. Other conventional diagnostic apparatuses are programmable to enable them to interface with a broader range of UUT equipment, but such programming must be manually entered by the maintenance personnel each time the apparatus is intended to be connected to a different model of UUT.
- A need exists for a diagnostic apparatus capable of interfacing with a broad range of UUT equipment models without requiring manual reprogramming by maintenance personnel.
- The invention is a diagnostic instrument or data acquisition apparatus having a database (the “attribute database”) for storing communications interface specifications and other properties of diagnostic attributes outputted by various classes (models and/or versions) of equipment to be tested (“unit under test” or “UUT”). The attribute database includes a plurality of attribute data records, each of which includes at least a first field identifying a class of UUT equipment and a second field identifying (e.g., by name or description) a diagnostic attribute whose value is outputted by that class of equipment. The attribute values (i.e., attribute data) outputted by a UUT can include sensor measurements and operating conditions.
- In one aspect of the invention, an attribute data record further includes a third field identifying an ID (e.g., physical signal line, physical address, or logical address) that enables a diagnostic apparatus to retrieve the value of the attribute identified by the second field from the class of UUT equipment identified by the first field of the record. For example, the ID may identify (a) a physical signal line or connector pin at which the UUT outputs the attribute value, (b) a logical or physical address that a diagnostic apparatus must send to the UUT to command the UUT to output the attribute value, or (c) a logical or physical address that the UUT outputs along with the attribute value in order to identify which attribute the value represents.
- In a second aspect of the invention, at least one class of UUT equipment identified in the database includes a plurality of communication interfaces via which a diagnostic apparatus can retrieve attribute data, and an attribute data record further includes a field identifying one of said communication interfaces;
- In a third aspect of the invention, an attribute data record further includes a field identifying a chamber position or other configuration parameter that distinguishes attributes within a class of attributes.
- In a fourth aspect of the invention, an attribute data record further includes a field containing one or more conversion parameters, such as a scale factor, for converting an electrical signal outputted by the equipment to a physical unit of measurement for the attribute value identified by the second field.
- In a fifth aspect of the invention, the aforesaid first field of some or all of the attribute data records is a compound field that includes a plurality of subordinate fields (sub-fields) that collectively identify a range of equipment models, a range of equipment versions, or a range of equipment revision dates that define the class of equipment identified by the first field.
- In addition to the aforesaid diagnostic apparatus, other aspects of the invention are the aforesaid attribute database, the methods of storing data in the attribute database as summarized above, and data processing apparatuses for performing the methods.
-
FIG. 1 is a schematic diagram of the diagnostic apparatus of the invention connected to a conventional UUT which is a semiconductor manufacturing mainframe having six process chambers. -
FIG. 2 is a schematic diagram of the fields in an attribute record of an attribute database according to a preferred embodiment of the invention. Subordinate fields are depicted below the compound field to which they belong. -
FIG. 3 is a schematic diagram of the values stored in three attribute records which represent an exemplary attribute whose ID changes in different versions of an exemplary model of UUT. -
FIG. 4 is a schematic diagram of two attribute records which can represent the same information as the three records ofFIG. 3 . -
FIG. 5 is a schematic diagram of a system in which the attribute database is remote from the diagnostic apparatus. -
FIG. 6 is a flow chart showing the steps by which the diagnostic apparatus retrieves attribute data from a UUT using information stored in the attribute database. -
FIG. 7 is a database table representing the attribute database having the fields shown inFIG. 2 . -
FIG. 8 is a database table showing the database ofFIG. 7 divided into two tables. - Conventional UUT and Diagnostic Apparatus
- Before describing the novel diagnostic apparatus and database, it will be helpful to describe how UUT's generally communicate with conventional diagnostic apparatuses.
- While the UUT (“unit under test”) can be any type of electronic equipment, the exemplary UUT 12 shown in
FIG. 1 is similar to a semiconductor fabrication equipment “mainframe” or “platform” commercially sold as the Precision 5000 model by Applied Materials, Inc., the assignee of the present invention. The illustrated mainframe is designed to integrate up to six process chambers 21-26 which perform various semiconductor fabrication processes. For example, threechambers chamber 24 can be a heating chamber, and twochambers - (An actual Precision 5000 includes various components that are omitted here to simplify the illustration, such as loadlock chambers for receiving semiconductor wafers from a carrier outside the mainframe and a wafer transfer robot for transferring wafers between chambers.)
- One of the functions of the UUT
mainframe 12 is to provide a central communications interface orcommunications bus 31 for the chambers. Each chamber has adata port 32 connected to a correspondinginternal data port 33 of the mainframe. The mainframe'sinternal data ports 33 may all be connected to acommon communications channel 31. The mainframe includes a computer processor (CPU) 30 that controls the sequence and operating conditions of the semiconductor fabrication processes performed in the process chambers and controls data transfer among all of the mainframe's internal and external data ports. The mainframe can transmit data through its internal data ports to the chambers so as to set the values of various chamber operating parameters, such as chamber pressure, pedestal temperature, and RF power. - Each of the chambers also can be fitted with sensors or
measurement instruments 50 to measure operating conditions in the chamber, such as gas pressure, RF reflected power, or the intensity of optical emissions at certain wavelengths. The mainframe can include additionalinternal data ports 52 to receive measurement values from the measurement instruments and to send commands for controlling the measurement instruments. - The diagnostic attributes or collectible attributes of the
UUT 12, referred to herein simply as “attributes,” include all the operating conditions and measurement values described in the two preceding paragraphs. Specifically, the “attributes” of theUUT 12 are defined as the set of operating conditions and sensor measurements whose values can be outputted by the UUT, by the chambers 21-26 or other apparatus connected to the UUT, or by themeasurement instruments 50 connected to the chambers or the UUT. The attribute values outputted by the UUT or any of the chambers or instruments attached to the UUT are collectively referred to as “attribute data”. - The UUT 12 has at least one external communications interface or I/O (input/output) port through which it can transmit attribute data to an external device such as a factory controller computer or a
diagnostic apparatus 10. Generally the principal external communications interface is adigital interface 14 such as a conventional RS-232 serial port or a conventional Ethernet port. The UUT also may have one or moreanalog communications interfaces 15, typically for the purpose of outputting measurement values frommeasurement instruments 50 that produceanalog output signals 52. - A conventional
diagnostic apparatus 10 intended to monitor a given type of UUT will have one or more communications interfaces (I/O ports) compatible with, and capable of electrical connection to, the external communications interfaces of that type of UUT. For example, to connect to the exemplary UUT, a diagnostic apparatus should have adigital communications interface 18 and one or moreanalog communications interfaces 17 respectively connected to the UUT'sdigital interface 14 andanalog interfaces 15. (For purposes of illustration, the UUT inFIG. 1 includes analog interfaces, whereas the commercially sold Precision 5000 mainframe does not include an analog interface.) - In addition, some process chambers and some measurement instruments may output attribute data via digital or
analog communications interfaces 54 that are not connected to the UUT. To receive this attribute data, thediagnostic apparatus 10 may includeadditional communications interfaces 19 connected to thecommunications interfaces 54 of the chambers and measurement instruments. - Because attribute data may be outputted by a UUT, by a chamber or other apparatus connected to the UUT, or by a measurement instrument coupled to such a chamber or to the UUT, the term “attribute data source” or simply “data source” is used herein to refer to any apparatus connected directly or indirectly to the UUT that can output attribute data. Furthermore, all references herein to attribute data outputted by a UUT are intended to include attribute data outputted by any attribute data source connected directly or indirectly to that UUT.
- The numerous conventional digital communications protocols by which a UUT or other attribute data source can output digital data through an external communications interface generally fall within either of two categories: command-driven protocols and continuous streaming protocols.
- In a command-driven protocol, the data source outputs attribute data only in response to “read” commands received by the data source at its digital communications interface. Specifically, a
diagnostic apparatus 10 can receive from the data source the value of a particular attribute only by transmitting to the digital I/O interface - Besides responding to “read” commands, some attribute data sources also respond to “write” commands via the digital I/
O interface - In a continuous streaming communications protocol for outputting digital data, a UUT or other data source outputs a continuous stream of attribute data through its external
digital communications interface - In a variant of the continuous streaming protocol, often called “trace mode” protocol, a UUT or other attribute data source only outputs the values of certain attributes in a continuous streaming format. A diagnostic apparatus can select which attributes are included in the “stream” by sending “trace mode” commands to the data source which identify the selected attributes.
- Semiconductor fabrication equipment that implements the published data communications standard known as SECS-2 generally can output attribute data using both a command-driven protocol and a trace mode protocol.
- Regardless of whether the UUT and its associated attribute data sources transmit digital attribute data via a command-driven protocol, a continuous protocol, or both, it is important for the
diagnostic apparatus 10 to know the ID corresponding to each diagnostic attribute for every class of UUT with which the diagnostic apparatus will be used. - As stated above, the UUT or its associated attribute data sources also may have one or more analog communications interfaces 15 for outputting measurement values from measurement instruments or sensors that produce attribute data in the form of analog output signals. Each analog interface may have one or more signal lines that can each transmit the analog value of a different attribute. In that case, it is important for the diagnostic apparatus to know which attribute corresponds to (i.e., is transmitted by) each signal line of each analog interface.
- Various mainframe models differ in the number of process chambers to which they can be connected. In
mainframes 12 to which multiple chambers 21-26 can be connected, it is important to identify which chamber a given attribute value applies to. Accordingly, a given class of diagnostic attribute has a different ID for each chamber. An example of a “class” of attribute is chamber pressure. The chamber pressure in thefirst chamber 21 and the chamber pressure in thesecond chamber 22 would be distinguished by having different ID's. - Various process chamber models have different classes of attributes. For example, RF power is an attribute of a plasma chamber but not a thermal deposition chamber, whereas heat lamp power typically is an attribute of the latter but not the former. As another example, some plasma chambers have two RF power supplies with independently controllable powers and RF frequencies, while other plasma chambers have only one RF power supply.
- Various mainframe models also have different classes of attributes that relate to the mainframe itself rather than to one of the process chambers and that can be received or transmitted at the external communications interface of the mainframe. An example of a mainframe attribute is the position of a wafer transfer robot. Some mainframe models have only one robot while others have two, hence the former mainframes would not accept commands to control the position of a second robot or the pressure within the transfer chamber housing the second robot.
- Even to the extent that different UUT or mainframe models have common attributes, such as chamber pressure and susceptor temperature, different mainframe models typically assign different ID's to those attributes. For example, for one mainframe model the chamber pressure in process chamber number one may have an ID of “12345”, whereas the corresponding chamber pressure may have an ID of “ABC” for a second mainframe model. Furthermore, those UUT's that have multiple external communications interfaces may differ in the correspondence between attributes and interfaces, i.e., for each diagnostic attribute, which interface and which signal line on that interface transmits that attribute.
- UUT's also differ in the format in which they encode the attributes. For example, they may differ in terms of the conversion factors required to convert the digital values which they transmit via their external communications interface to physical attributes such as temperature and pressure.
- Because of the many differences among classes of UUT's as just described, a conventional diagnostic apparatus typically is limited to receiving data from one model, or a small number of models, of UUT for which the diagnostic apparatus understands how to retrieve the attributes.
- Attribute Database
- My novel
diagnostic apparatus 10 adds to the conventional diagnostic apparatus described above a novel database containing communications interface specifications enabling thediagnostic apparatus 10 to communicate with many different classes (models and/or versions) of UUT's 12. The database contains a table, referred to herein as the “attribute table” or “attribute database”, that stores a list of the attributes that each class of UUT can output via its external communications interface. For each attribute, the attribute database stores the ID that enables the diagnostic apparatus to retrieve the value of that attribute. - The diagnostic apparatus can be conventional in every respect except for the inclusion of the attribute database. As described below under the heading “Hardware Implementation,” the database can be stored on any conventional
data storage device 60, which can be located within the diagnostic apparatus or can be located remotely and connected to the diagnostic apparatus via a communications network. - In the embodiment illustrated in
FIG. 2 , the attribute database contains a distinct database record for each combination of UUT class and attribute. That is, the attribute database contains a distinct group (i.e., “set”) of records for each class (model or version) of UUT equipment, and the set of records for a given mainframe class includes a distinct record for each attribute that can be transmitted to or received from that mainframe class. (Alternative embodiments for reducing the required number of records are described below under the headings “Version Ranges” and “Database Normalization”.) - As described above, if the UUT is a mainframe apparatus designed to be connected to various classes of process chambers 21-26 and/or measuring instruments, the diagnostic attributes can include attributes outputted by the mainframe itself, by the various classes of process chambers that can be attached to that mainframe, and by the various instruments that can be coupled to that mainframe or its process chambers, all of which are collectively referred to as “data source apparatuses”.
- Each record stored in the attribute database is referred to herein as an “attribute record”.
FIG. 2 shows the data fields that preferably are included in the attribute database. The left-to-right order of the illustrated fields is arbitrary; the fields can be stored within each database record in any physical or temporal order. - In the embodiment shown in
FIG. 2 , each attribute record includes every field. Alternative embodiments that use multiple, related database tables to reduce entry of redundant data in the attribute records are described below, under the heading “Database Normalization.” - “UUT Class” Field
- The “UUT Class” field of each attribute record identifies the class of equipment to which the remaining fields in the record pertain. The attribute database can be used to store information about many different models of UUT's, where each model can have various versions. Accordingly, in the preferred embodiment, the “UUT Class” field has two subordinate fields called “Model” and “Version”. The value stored in the “Model” field identifies an individual equipment model, and the value stored in the “Version” field identifies a specific version of the equipment model specified in the “Model” field.
- Any of the fields in an attribute record can be either a simple field that stores a single value or a “compound field” that stores a plurality of values. We define a “compound field” as a plurality of fields, which we call “subordinate fields” or “sub-fields”, whose respective values collectively specify the value of the parameter represented by the compound field. For example, the “UUT Class” field described in the preceding paragraph is a compound field. The UUT Class is completely and uniquely identified by designating an equipment model in the “Model” sub-field and designating a version of that model in the “Version” sub-field.
- A subordinate field can itself be a compound field; that is, a subordinate field can include a plurality of further subordinate fields. For example, as described below under the heading “Version Ranges”, the “Version” field can include “Version, First” and “Version, Last” sub-fields enabling the “Version” field to identify a range of equipment versions instead of a single version.
- As described below under the heading “Database Normalization,” the sub-fields of a given compound field can be stored in different, related database tables, but still are considered sub-fields of the same compound field for purposed of this patent specification.
- “Attribute” Field
- The “Attribute” field contains the name of the diagnostic attribute whose ID and other properties (e.g., physical units and conversion factors) are described by the remaining fields of the attribute record. As stated above, diagnostic attributes of a UUT include all sensor measurements and operating conditions of the UUT and of all chambers, measuring instruments and other apparatus attached directly or indirectly to the UUT. The attribute database includes a separate attribute record for each diagnostic attribute that the class of UUT identified in the “UUT Class” field is capable of outputting.
- For classes of UUT's that are
mainframes 12 designed to connect to multiple chambers 21-26 as shown inFIG. 1 , it is important to identify which chamber a given attribute value applies to. Typically, the mainframe will assign different ID's to distinguish the same attribute from different chambers. - Since an attribute that relates to a chamber is uniquely specified only if both the attribute name and the chamber position are specified, the “Attribute” field in an attribute record for a chamber-related attribute should include two subordinate fields, a “Attribute Name” field and a “Chamber Position” field, as shown in
FIG. 2 . For every chamber-related attribute, the database should include a separate record for each chamber position on the mainframe. This enables the attribute database to store (in the “ID” field of each record) the unique ID assigned by the mainframe to each attribute associated with each chamber position. - Conversely, if the attribute specified in the “Attribute” field relates to the mainframe itself rather than to one of the chambers connected to the mainframe, the “Chamber Position” field has no relevance, so the “Chamber Position” field can be omitted, or else the value of the field can be set to zero or empty.
- For example, one model of
mainframe 12 may be capable of attachment to up to six process chambers as shown inFIG. 1 . Suppose that one of the measured attributes for each chamber is the pressure within that chamber. In that case, the Attribute Name of “pressure” will not completely and uniquely identify a single diagnostic attribute. Instead, a complete identification of a “pressure” attribute would have to specify the Chamber Position, such as “pressure inchamber 1”, “pressure inchamber 2”, etc. Generally, the mainframe will assign six distinct ID's to be used by a diagnostic apparatus to retrieve the pressure measurement for the respective six chambers. These ID's will be stored in the database in the form of six distinct database records, where each record has the same name “pressure” stored in the “Attribute Name” field but has a distinct one of thevalues 1 through 6 in the “Chamber Position” field and has the corresponding one of the six ID's in the “ID” field. - In many cases, the “Attribute” field requires one or more additional sub-fields because the Attribute Name and Chamber Position do not suffice to uniquely determine the ID required to retrieve the attribute.
FIG. 2 illustrates that one possible additional sub-field is “Chamber Model”. As described above under the heading “Conventional UUT and Diagnostic Apparatus,” themainframe UUT 12 shown inFIG. 1 can be connected to several different types of chambers, such as plasma CVD chambers 21-23,heating chamber 24, andplasma etch chambers - Although some classes of diagnostic attributes are shared by these different chamber types and models, different chamber models often will not assign the same ID to a given diagnostic attribute. For example, the ID required to retrieve the cathode temperature may be “123” for a model MxP attached to the mainframe at chamber position 6 and “456” for a model “Super-e” chamber at the same position. In this example, therefore, the three sub-fields “Attribute Name”, “Chamber Position”, and “Chamber Model” are required to completely and uniquely identify a diagnostic attribute, such as “cathode temperature in an MxP Etch chamber at position 6”, which would be represented by an attribute record in which the values stored in these three respective fields would be “cathode temperature”, “6”, and “MxP Etch”, respectively.
-
FIG. 2 labels the “Chamber Model” sub-field as “Chamber Model or Config” to denote that one or more other parameters representing the configuration of the UUT or the chamber can be substituted for the Chamber Model in this field. - For classes of UUT's that have only a single, permanent process chamber, such as ion implant machines, the “Attribute” field need not include any sub-fields. In that case, the “Attribute” field should perform the same function as the previously described “Attribute Name” sub-field, i.e., it should store the name or description of the diagnostic attribute whose properties are described by the remaining fields of the attribute record.
- Each attribute record optionally may further include a “Read/Write” field as shown in
FIG. 2 . This field may be used to store a logical “flag” that indicates whether the diagnostic attribute specified in the “Attribute” field: (1) can be read (i.e., retrieved or collected) but not modified by a diagnostic apparatus; (2) can be read and modified (i.e., “written”); or (3) can be modified but not read. - “Interface & Protocol” Field
- As shown in
FIG. 2 , each attribute record preferably includes an “Interface & Protocol” field. If the UUT has more than oneexternal communications interface 18 such that the different external interfaces output different diagnostic attributes, then the value stored in the “Interface & Protocol” field should identify which physical interface of the UUT outputs the diagnostic attribute specified in the “Attribute” field. Likewise, if the UUT can have chambers or instruments with external interfaces separate from those of the UUT, the “Interface & Protocol” field identifies which of these interfaces can output the attribute specified in the “Attribute” field. - The “Interface & Protocol” field preferably should identify the analog or digital hardware protocol and, optionally, the low level communications protocols by which the UUT outputs attribute data at the specified interface. Examples of hardware protocols that might be employed at different communications interfaces are RS-232 and Ethernet. Examples of communications protocols that different UUT's might employ are SECS, GEM, and IP. The “Interface & Protocol” field also can be used to specify the type of electrical connector used for that interface, such as DB-9, DB-25 or RJ-45. All the hardware and communications protocols mentioned in this paragraph are published standards.
- The “Interface & Protocol” field can be omitted from the attribute database if all the UUT classes recorded in the database employ the same communications protocol for outputting attribute data, and if none of the UUT classes requires more than one external communications interface to output the attribute data.
- The reason the interface and protocol are represented by a single field in
FIG. 2 is that the communications protocols used at a given interface generally will be the same for all diagnostic attributes outputted at that interface. That is, a UUT or other data source would not employ different protocols for outputting different diagnostic attributes via the same interface. Therefore, there is no need to permit the interface and the protocols to be specified independently of each other in separate fields. - However, in actual programming of the database structure, it may be more convenient to divide the “Interface & Protocol” field into separate sub-fields for each level of hardware and communications protocol discussed in the preceding paragraph. A common practice in designing a relational database would be to define a “Interface & Protocol” table having separate fields for each of these protocol levels. The “Interface & Protocol” table should be “related” to the “Attribute” table shown in
FIG. 2 via the “Interface & Protocol” field in the “Attribute” table. - “ID” Field
- The “ID” field contains the ID that enables a diagnostic apparatus to retrieve (i.e., read or collect) the value of the diagnostic attribute identified by the “Attribute” field from the class of UUT equipment identified by the “UUT Class” field of the attribute record. As explained earlier, a UUT conventionally assigns a unique ID to every diagnostic attribute it can output from a given external communications interface.
- The meaning of the ID depends on the type of communications interface and protocol employed by the UUT for outputting that diagnostic attribute. As just discussed, the communications protocol preferably is specified in the “Interface & Protocol” field.
- If the “Interface & Protocol” field specifies an analog interface with multiple signal lines carrying different attribute data, the “ID” field should identify which signal lines (e.g., which pins on an electrical connector) carry the specified attribute.
- If the “Interface & Protocol” field specifies a digital interface using a command-driven communications protocol, the “ID” field should specify the logical or physical address that must be included in a “read” command sent from the diagnostic apparatus to the UUT in order to retrieve the attribute specified in the “Attribute” field.
- If the “Interface & Protocol” field specifies a digital interface using a continuously streaming communications protocol, the “ID” field should specify the logical or physical address transmitted by the UUT to identify the attribute data, or the logical address or offset that identifies the position of the specified attribute data within a “frame” of data that is periodically outputted by the UUT.
- Hardware Implementation
- As explained above, a
UUT 12 has at least oneexternal communications interface 14 through which it outputs attribute data. Thediagnostic apparatus 10 should have acommunications interface 18 compatible with, and connected to, theexternal communications interface 14 of the UUT. The diagnostic apparatus can have a number of communications interfaces of different types to permit connection to different types of interfaces on different classes of UUT's. - If the
UUT 12 is a conventional semiconductor fabrication tool or mainframe, itsexternal communications interface 14 generally will be a digital interface complying with the well known RS-232 serial communications standard, and it will transfer data in response to the commands specified in the published “SECS” communications protocol that is widely adopted in the semiconductor industry. Adiagnostic apparatus 10 for monitoring such semiconductor mainframes conventionally can include a general purpose “PC”computer 62 running the well known Windows, Macintosh, or Linux operating system. Alternatively, thediagnostic apparatus 10 can include acomputer 62 specifically intended for monitoring semiconductor fabrication tools, such as the “Blue Box” model computer sold by MKS Instruments, a company in Andover, Mass. Either type ofcomputer 62 commonly has an RS-232serial port 18 that can be connected to the RS-232 port of the UUT via a conventional serial cable. Conventional data collection and analysis software can be installed on the computer. Such software can control data transfer through the communications interfaces of the diagnostic apparatus in compliance with the communications protocol used by the UUT, such as the SECS protocol, so as to retrieve desired attribute data from the UUT. The software also can present the retrieved attribute data to service personnel, store or “log” the data in a conventionalcomputer storage device 60, signal an alert upon detecting the occurrence of certain conditions in the retrieved attribute data, and perform statistical analysis of the data. For example, software with these capabilities is commercially sold by MKS Instruments and by Brookside Software, a company in San Carlos, Calif. - In operation, a human user will instruct the diagnostic apparatus to retrieve certain attribute data from the UUT. The instruction may be in the form of a manually typed command, a push button, or a computer program stored by a user in the diagnostic apparatus that specifies a sequence in which several attributes should be retrieved in accordance with a data collection plan. These are all conventional features of the aforesaid, commercially available, data collection software and computer hardware.
- To implement our invention, the attribute database described above can be added to one of the just-described conventional
diagnostic apparatuses 10 that is based on aprogrammable computer 62. - The attribute database records can be stored on any conventional
data storage device 60, such as one or more computer hard disk drives. The logical structure of the attribute database, in the form of the records and fields described in this patent specification, can be implemented by straightforward programming of any conventional database management system (DBMS) software installed on aconventional computer 62. DBMS software is commercially sold by various software companies such as Microsoft, IBM and Oracle. Open source SQL DBMS software also is publicly available. Of course, the data storage device can be connected to the computer by any conventional data interface. - That attribute database and the DBMS software can be installed on the
data storage device 60 and thecomputer 62 within thediagnostic apparatus 10 shown inFIG. 1 . Both the DBMS software and the previously described data collection and analysis software can be installed and simultaneously running on thesame computer 62. - More preferably, as shown in
FIG. 5 , the attribute database and the DBMS software can be installed on adata storage device 64 and aserver computer 66 at a remote location. Thediagnostic apparatus 10 can connect to theserver computer 66 via a conventional data communications link 68, such as a local area network, a wide area network, or a point-to-point link via telephone. The DBMS software installed on theserver computer 66 preferably has multi-user server capability so that manydiagnostic apparatuses 10 at different locations can simultaneously access the database. - For example, the
data storage device 64 on which the attribute database is installed can be located at a central office where it can be readily updated from time to time to include new models and new versions of UUT's. Portablediagnostic apparatuses 10 can be carried to customer sites throughout the world to service customer-owned UUT's. Each diagnostic apparatus can access the database via acommunications link 68. - If the attribute database is installed on a remotely located 64 and
server computer 66 as shown inFIG. 5 , then eachdiagnostic apparatus 10 should include acomputer 62 in which conventional database client software has been installed. Such software is conventionally capable of sending a request via the communications link 68 to theserver computer 66 whenever the diagnostic apparatus needs to retrieve a database record, such as to determine the ID or other properties of an attribute. Thecomputer 62 within eachdiagnostic apparatus 10 also should include the previously described conventional software for communicating with the UUT to retrieve attribute data. - Operation
- Before the diagnostic apparatus is used to retrieve attribute data from a given class (model and version) of UUT, the previously described attribute records (
FIG. 2 ) which characterize the diagnostic attributes for that class of UUT should be stored in the attribute database. Generally, the manufacturer of the UUT supplies the ID and other properties of each diagnostic attribute that the UUT is capable of transmitting. Therefore, the user of the diagnostic apparatus can acquire such attribute properties from the UUT manufacturer and store the information in the attribute database in accordance with the database structure described above. Preferably, the manufacturer of the UUT can store the information directly in the database (i.e., build or populate the database) to avoid the need for the user to acquire the information from the manufacturer and reformat it for storage in the database. -
FIG. 6 is a flow chart showing the steps by which adiagnostic apparatus 10 retrieves attribute data from a UUT using the previously described attribute database. These steps preferably are implemented by straightforward programming of thecomputer 62 within the diagnostic apparatus. The software that implements the following Steps 601-607 is referred to herein as the Attribute Look-Up software. The Attribute Look-Up software preferably is installed in thesame computer 62 within thediagnostic apparatus 10 that runs the conventional data collection and analysis software described under the heading “Hardware Implementation”. All of this software can run simultaneously on the computer. - Step 601: The diagnostic apparatus must identify what class (model and version) of UUT it is connected to. Some conventional UUT's are capable of identifying themselves in response to a command sent by the diagnostic apparatus to a
digital communications interface 14 of the UUT. With UUT's that lack such capability, the person using the diagnostic apparatus is responsible for identifying the UUT and providing this information to the diagnostic apparatus, such as via keyboard input. As explained in the preceding sections entitled “Attribute Database” and “UUT Class Field,” the information required to uniquely identify a class of UUT includes a model designation, and a version designation (e.g., version number or version date) may be necessary to uniquely identify the class of UUT if different versions have different attribute properties. - Step 602: Optionally, if the attribute database is stored on a
remote server 66, the diagnostic apparatus can transfer from the server'sstorage device 64 to its local storage device 60 a copy of all the attribute records for the identified class of UUT, that is, all attribute records whose “UUT Class” field matches the class of UUT identified inStep 601. Thisoptional Step 602 eliminates the need to maintain a continuous communications link 68 with the remote server during subsequent operation of the diagnostic apparatus, since the communications link is required only during thisStep 602. This step is accomplished by a database client software on thelocal computer 62 sending a query to DBMS server software on theserver computer 66. - Step 603: The diagnostic apparatus must identify one or more attributes that service personnel select to retrieve from the UUT. The selected attributes may be manually identified by keyboard input, or may be specified in a data collection plan that service personnel previously stored in the computer of the diagnostic apparatus. This step may be performed before, after, or concurrently with
Step 601. For attributes that are associated with a chamber attached to a multi-chamber UUT, the identification of the attribute should include identifying the chamber model, chamber position, and any other applicable chamber configuration parameters, as explained in the preceding section entitled “Attribute Field.” - Step 604: For each attribute selected in
Step 603, the diagnostic apparatus queries the attribute database to retrieve the one attribute record corresponding to both the UUT class identified inStep 601 and the selected attribute. Ifoptional Step 602 was performed, the diagnostic apparatus can search the attribute records transferred to its local storage device inStep 602 to find the one attribute record whose “Attribute” field matches the selected attribute. Otherwise, conventional database client software on thelocal computer 62 should send a query to DBMS server software on theserver computer 66 to retrieve the one attribute record whose “UUT Class” field matches the UUT class identified inStep 601 and whose “Attribute” field matches the selected attribute. - Step 605: For each attribute record retrieved in
Step 604, the diagnostic apparatus reads the ID of that attribute from the “ID” field of the record. If such fields are included in the attribute record, the diagnostic apparatus also reads the interface and protocol information from the “Interface & Protocol” field of the record, and reads the read/write flag from the “Read/Write” field of the record. - Step 606: The diagnostic apparatus now retrieves the actual attribute data from the external communications interface of the UUT using the ID, the interface information, and the protocol information from
Step 605. If the UUT and its associated data sources collectively have more than one external communications interface, the interface information specifies from which interface the diagnostic apparatus should retrieve the attribute data in this step. The protocol information specifies the retrieval method required by the UUT; it typically will be one of the methods described in the preceding sections entitled “Conventional UUT and Diagnostic Apparatus” and “Interface & Protocol Field”. - For example, if the
UUT 12 employs a command-driven protocol for outputting that attribute data, the diagnostic apparatus sends to the UUT a “read” command specifying the ID. As another example, if the UUT transmits the attribute data in a continuous streaming protocol as described above, thediagnostic apparatus 10 uses the ID of the desired attribute to locate the attribute data in the stream of data from the UUT. Alternatively, if the UUT outputs the specified attribute at an analog interface, the diagnostic apparatus simply reads the analog signal from the interface specified in the “Interface & Protocol” field. If the interface has multiple signal lines, the “ID” field should specify from which signal line of the interface the diagnostic apparatus should read the analog signal. - Preferably, the
computer 62 of the diagnostic apparatus includes conventional data collection software as described under the heading “Hardware Implementation”. If so, inStep 606 the Attribute Look-Up software preferably passes the ID, the interface information, and the protocol information obtained inStep 605 to the data collection software, which employs the specified communications protocol to retrieve the attribute data from the UUT. - Step 607: If the attribute record includes a “Conversion” field or “Scale Factor” field value, apply the conversion or scale factor specified in the attribute record. If the attribute record includes a “Physical Units” field value, store that value along with the attribute data. These fields are explained below under the heading “Conversion to Physical Units.”
- Conversion to Physical Units
- Each database record can further include a “Conversion” field that contains one or more subordinate fields, each of which stores a conversion parameter, such as a scale factor, for converting the analog or digital electrical signal outputted by the UUT to a physical unit of measurement for the attribute value identified by the “Attribute” field. An additional subordinate field of the “Conversion” field can specify the units of such physical unit of measurement, such as “watts”, “degrees Celsius”, “torr”, or “sccm”.
- In many models of mainframes commercially sold by the assignee of this invention, the attribute data outputted by the mainframe is an N-bit binary number whose possible values range from zero to 2N−1, where the binary values of zero and 2N−1 respectively represent a minimum physical value and a maximum physical value for the attribute. For such attributes, the “Conversion” field preferably consists of three subordinate fields: “Min”, “Max” and “Units”. The numerical values stored in the “Min” and “Max” fields are the physical attribute values represented by the attribute data having binary values of zero and 2N−1, respectively. The value stored in the “Units” field designates the physical units in which such physical attribute values are expressed.
- For example, suppose that one of the attributes outputted by a mainframe is the temperature of the susceptor in the third chamber, and suppose that the range temperature measurements is 50° C. to 550° C. Accordingly, the mainframe should output binary values in the range of zero to 2N−1 to represent temperatures in the range of 50° C. to 550° C. In that case, values of “50” and “550” should be stored in the “Min” and “Max” fields, respectively, of the database record for the temperature of the susceptor in the third chamber, and the value “degrees Celsius” should be stored in the “Units” field of that record.
- Version Ranges
- As described in the preceding sections entitled “Attribute Database” and “UUT Class Field,” the “UUT Class” field of each database record identifies the class of equipment to which the remaining fields in the record pertain. In general, the class of UUT can be defined by the equipment model, equipment version, or a combination of both. That is, the classes of UUT's may include various equipment models, and each model of UUT may be produced in various versions or generations having some differences in the specifications of their attributes. To enable the database to record the differences among various models of UUT's as well as various versions or generations of each model, the “UUT Class” field of each database record is a combination field that includes a “Model” subordinate field and a “Version” subordinate field. In other words, each version of each model of mainframe equipment is considered a distinct UUT Class.
- The value stored in the “Version” field to identify a version or generation may be, for example, a version number or a version date. The versions of a given model of UUT may differ from each other in either their physical features or their operating software. If the versions differ from each other in what diagnostic attributes the UUT outputs via its external communications interface, or in the properties of the transmitted attributes (e.g., the respective ID's or conversion factors associated with one or more attributes), then it would be useful to employ the attribute database of the present invention to track these differences.
- The attribute database of the present invention is useful to tabulate differences between versions even when a diagnostic apparatus will only be connected to a single model of UUT equipment. In that case, there would be no need for the “Model” sub-field of the “UUT Class” field. In other words, the “UUT Class” field would simply be the “Version” field.
- Returning to the more general case in which the UUT Class is defined by both model and version, in one embodiment the attribute database contains a distinct set of records for each UUT class, and the set of records for a given UUT class includes a distinct record for each diagnostic attribute that can be outputted by that model and version of the UUT. For example, if a given model of mainframe equipment has undergone 20 versions of software and/or hardware changes during its history, and if each version of that model has 30 attributes, then the database will require 600 records (20 versions multiplied by 30 attributes per version) to store the specifications of the attributes for all versions of that model.
- A more preferable embodiment of the attribute database reduces the required number of records by enabling the “Version” field of each attribute record to represent a range of versions instead of just a single version. Specifically, if the interface specifications and other properties of a given diagnostic attribute remain the same for a range of versions of a given model of UUT, a single record is stored in the database to characterize that diagnostic attribute for all the versions within that range, rather than storing a distinct record for each version.
-
FIG. 3 shows the implementation of this technique in which the “Version” field in each database record is a compound field that includes two subordinate fields called “Version, First” and “Version, Last” whose contents respectively identify the first and last versions of the UUT model identified in the “Model” field to which the remaining fields of the record apply. In this embodiment of the invention, we define a “UUT Class” as a range of one or more versions of a specific model of UUT. - For example, suppose a mainframe model called “Alpha” has undergone 20 revisions during its history. Suppose that in versions 1-7 of the Alpha mainframe, the attribute “Pressure in
Chamber 1” was assigned tological port 33; in versions 8-16, this attribute was assigned a new logical port of 44; and in versions 17-20, this attribute was assigned tological port 33 again. As shown inFIG. 3 , these revisions can be represented by three database records instead of twenty. -
FIG. 4 shows an alternative embodiment in which the “Version” field can specify a plurality of versions that are not contiguous, and hence that cannot be defined as a range bounded by a first version and a last version. In this embodiment, the “Version” field can include any number of subordinate fields that each identify a version of the UUT model to which the record applies, so that the subordinate fields collectively identify a set of UUT versions. In the example of the preceding paragraph, the attribute “Pressure inChamber 1” of Alpha can be represented by only two records in the database: one record for versions 1-7 and 18-20, and a second record for versions 8-17, as shown inFIG. 4 . The first database record has a “Version” field consisting of four subordinate fields called “1-Version, First”, “1-Version, Last”, “2-Version, First” and “2-Version, Last” in which are stored the respective values “1”, “7”, “17” and “20”. - Although versions conventionally are identified by version numbers, non-numeric names also can be used to identify different versions.
- Alternatively, versions can be identified by date rather than version number. For example, in the embodiment shown in
FIG. 2 , the “Version” field of an attribute data record could store the release date, rather than a version number, of the UUT class to which that attribute data record applies. Similarly, in the embodiment shown inFIG. 3 , the “Version, First” and “Version, Last” fields could store the first production date and the last production date of the UUT class to which the record applies, signifying that the attribute data record applies to all equipments of that UUT class that were produced between the specified first and last production dates. - Database Normalization
-
FIG. 2 , discussed extensively above, depicts the fields in a record of the attribute database. The identical database structure is depicted inFIG. 7 in the form of a table. In the database tables shown inFIGS. 7 and 8 , the notation “A:B” for a field name represents the sub-field named “B” of the compound field named “A”. -
FIG. 8 shows how the database can be at least partially normalized by dividing it into two tables called the “Attribute” table and the “Attribute Name & Chamber Config” table. To normalize the database, fields whose values rarely or never change independently of each other are grouped into a table. The normalized database reduces storage requirements by eliminating redundant fields in the records of the main database table, the Attribute table. - In each database table, the first field listed is the key field of the table, which means that every record of the table has a different value stored in the key field. In the Attribute table, the ID is the key field because every attribute has a different ID.
- Diagnostic attributes that represent operating conditions or measurements for a process chamber, as opposed to the mainframe, usually are converted from analog measurements into digital attribute data using analog-to-digital converters within the chamber or within the measurement instrument attached to the chamber. Consequently, the conversion parameters (units and scale factor), as well as whether a parameter is read-only or read/write, usually are determined entirely by the chamber model and chamber configuration and are independent of the model and version of the UUT to which the chamber is connected. Logically, the conversion parameters also are independent of the chamber position on the mainframe at which a given process chamber is mounted. Therefore, the database fields that represent the conversion parameters and the read/write flag can be moved from the Attribute table to a “child” table.
- Besides the conversion parameters and read/write flag, the additional fields included in the “child” table are the fields necessary to uniquely determine the values of the conversion parameters and the read/write flag. These additional fields are, for the reasons explained in the preceding paragraph, the “Attribute: Name” field and the “Attribute: Chamber Model or Config” field. These two fields collectively define the key field of the database table. Therefore, the child table is named the “Attribute Name & Chamber Config” table. The value stored in the key field for each record of the table can be either an arbitrary index number or can be formed by concatenating the values of the “Attribute: Name” field and the “Attribute: Chamber Model or Config” field for that record.
- The advantage of creating the “Attribute Name & Chamber Config” table is that Attribute table now only needs to include a single field for the “Attribute Name & Chamber Config Key” in place of the six fields previously required for the “Attribute: Name”, “Attribute: Chamber Model or Config”, “Read/Write”, “Conversion: Units”, “Conversion: Scale Factor: Min”, and “Conversion: Scale Factor: Max”. This reduces the storage required for the database.
Claims (45)
1. A method of storing information in a database to characterize attributes outputted by different classes of equipment, comprising the steps of:
providing a database memory device;
storing in the database memory device a plurality of attribute data records, wherein the step of storing each attribute data record includes:
storing in that record a first field identifying a class of equipment, storing in that record a second field identifying an attribute whose value is outputted by the class of equipment identified by the first field of that record, and storing in that record a third field specifying an ID which the class of equipment identified by the first field of that record assigns to the attribute value identified by the second field of that record.
2. The method of claim 1 , wherein, for each attribute data record, the ID stored in the third field uniquely specifies the attribute stored in the second field for the class of equipment stored in the first field.
3. The method of claim 1 , wherein, for each attribute data record, the ID stored in the third field uniquely specifies a command in response to which the class of equipment stored in the first field outputs the attribute stored in the second field.
4. The method of claim 1 , wherein, for each attribute data record, the ID stored in the third field uniquely specifies a command such that, in response to the class of equipment stored in the first field receiving said command, said class of equipment outputs the attribute stored in the second field.
5. The method of claim 1 , wherein, for at least one attribute data record, the step of storing the second field further includes the step of:
storing a fourth field identifying a position of a chamber connected to the class of equipment identified in the first field.
6. The method of claim 1 , wherein, for each attribute data record, the first field identifies at least one model of equipment.
7. The method of claim 1 , wherein, for each attribute data record, the first field identifies at least one version of equipment.
8. The method of claim 1 , wherein, for at least one attribute data record, the step of storing the first field includes:
storing a first subordinate field that identifies a model of equipment; and
storing a second subordinate field that identifies a version of the model of equipment identified in the first subordinate field.
9. The method of claim 1 , wherein, for at least one attribute data record, the step of storing the first field includes:
storing first and second subordinate fields that collectively identify a range of versions of an equipment model.
10. The method of claim 9 , wherein the first and second subordinate fields respectively identify a first version and a last version in said range of versions.
11. The method of claim 1 , wherein, for at least one attribute data record, the step of storing the first field includes:
storing first and second subordinate fields that collectively identify a range of revision dates of an equipment model.
12. The method of claim 11 , wherein the first and second subordinate fields respectively identify a first revision date and a last revision date in said range of revision dates.
13. The method of claim 1 , wherein the step of storing a plurality of attribute database records comprises the steps of:
storing in the database memory a first record including said first field, wherein the first field of the first record identifies a first class of equipment that includes a first model of equipment; and
storing in the database memory a second record including said first field, wherein the first field of the second record identifies a second class of equipment that includes a second model of equipment different from the first model.
14. The method of claim 1 , wherein the step of storing a plurality of attribute database records comprises the steps of:
storing in the database memory a first record including said first field, wherein the first field of the first record identifies a first class of equipment that includes a first version of a first model of equipment; and
storing in the database memory a second record including said first field, wherein the first field of the second record identifies a second class of equipment that includes a second version of said first model of equipment, the second version being different from the first version.
15. The method of claim 1 , wherein, for at least one of the attribute data records, the attribute identified in the step of storing the first field is a measurement of a process being performed in a semiconductor fabrication process chamber.
16. The method of claim 1 , wherein, for at least one of the attribute data records, the attribute identified in the step of storing the first field is an operating condition of a process being performed in a semiconductor fabrication process chamber.
17. A method of storing information in a database to characterize attributes outputted by different classes of equipment, comprising the steps of:
providing a database memory device;
storing in the database memory device a plurality of attribute data records, wherein the step of storing each attribute data record includes:
storing in that record a first field identifying a class of equipment,
storing in that record a second field identifying an attribute whose value is outputted by the class of equipment identified by the first field of that record, and
storing in that record a third field specifying a conversion parameter that defines a conversion of the value of the attribute identified in the second field into physical units of measurement.
18. The method of claim 17 , wherein, for at least one of the attribute data records, the conversion parameter stored in the third field specifies a physical unit of measurement.
19. The method of claim 17 , wherein, for at least one of the attribute data records, the conversion parameter stored in the third field specifies a scale factor.
20. The method of claim 17 , wherein, for at least one of the attribute data records, the conversion parameter stored in the third field specifies a range of physical values.
21. A diagnostic apparatus for monitoring electronic equipment, comprising:
a computer-readable data storage device in which a plurality of data records are stored, wherein each data record includes:
a first data field that stores data identifying a class of equipment,
a second data field that stores data identifying an attribute whose value is outputted by the class of equipment identified by the first field of that record, and
a third data field that stores data specifying an ID which the class of equipment identified by the first field of that record assigns to the attribute value identified by the second field of that record; and
a computer connected to read data from the data storage device.
22. The apparatus of claim 21 , further comprising:
a communications interface capable of being connected to receive data from the class of equipment identified in one of the data records;
wherein the computer is connected to read data from the communications interface.
23. The apparatus of claim 21 , wherein, for each attribute data record, the ID stored in the third field uniquely specifies the attribute stored in the second field for the class of equipment stored in the first field.
24. The apparatus of claim 21 , wherein, for each attribute data record, the ID stored in the third field uniquely specifies a command in response to which the class of equipment stored in the first field outputs the attribute stored in the second field.
25. The apparatus of claim 21 , wherein, for each attribute data record, the ID stored in the third field uniquely specifies a command such that, in response to the class of equipment stored in the first field receiving said command, said class of equipment outputs the attribute stored in the second field.
26. The apparatus of claim 21 , wherein at least one attribute data record further includes a fourth data field that stores data identifying a position of a chamber connected to the class of equipment identified in the first field.
27. The apparatus of claim 21 , wherein, for each attribute data record, the first field stores data identifying at least one model of equipment.
28. The apparatus of claim 21 , wherein, for each attribute data record, the first field stores data identifying at least one version of equipment.
29. The apparatus of claim 21 , wherein, for at least one attribute data record, the first data field includes:
a first subordinate field that stores data identifying a model of equipment; and
a second subordinate field that stores data identifying a version of the model of equipment identified in the first subordinate field.
30. The apparatus of claim 21 , wherein, for at least one attribute data record, the first data field includes:
first and second subordinate fields that store data that collectively identify a range of versions of an equipment model.
31. The apparatus of claim 30 , wherein the data stored in the first and second subordinate fields respectively identify a first version and a last version in said range of versions.
32. The apparatus of claim 21 , wherein, for at least one attribute data record, the first data field includes:
first and second subordinate fields that store data that collectively identify a range of revision dates of an equipment model.
33. The apparatus of claim 32 , wherein the data stored in the first and second subordinate fields respectively identify a first revision date and a last revision date in said range of revision dates.
34. The apparatus of claim 21 , wherein the plurality of attribute database records stored in the computer-readable data storage device include:
a first record including said first field, wherein the data stored in the first field of the first record identifies a first class of equipment that includes a first model of equipment; and
a second record including said first field, wherein the data stored in the first field of the second record identifies a second class of equipment that includes a second model of equipment different from the first model.
35. The apparatus of claim 21 , wherein the plurality of attribute database records stored in the computer-readable data storage device comprises:
a first record including said first field, wherein the data stored in the first field of the first record identifies a first class of equipment that includes a first version of a first model of equipment; and
a second record including said first field, wherein the data stored in the first field of the second record identifies a second class of equipment that includes a second version of said first model of equipment, the second version being different from the first version.
36. The apparatus of claim 21 , wherein, for at least one of the attribute data records, the attribute identified by the data stored in the first field is a measurement of a process performed in a semiconductor fabrication process chamber.
37. The apparatus of claim 21 , wherein, for at least one of the attribute data records, the attribute identified by the data stored in the first field is an operating condition of a process performed in a semiconductor fabrication process chamber.
38. A diagnostic apparatus for monitoring electronic equipment, comprising:
a computer-readable data storage device in which a plurality of data records are stored, wherein each data record includes:
a first data field that stores data identifying a class of equipment,
a second data field that stores data identifying an attribute whose value is outputted by the class of equipment identified by the first field of that record, and
a third data field that stores data specifying a conversion parameter that defines a conversion of the value of the attribute identified in the second field into physical units of measurement; and
a computer connected to read data from the data storage device.
39. The apparatus of claim 38 , wherein, for at least one of the attribute data records, the conversion parameter stored in the third field specifies a physical unit of measurement.
40. The apparatus of claim 38 , wherein, for at least one of the attribute data records, the conversion parameter stored in the third field specifies a scale factor.
41. The apparatus of claim 38 , wherein, for at least one of the attribute data records, the conversion parameter stored in the third field specifies a range of physical values.
42. A data storage medium for storing data that describes one or more attributes of at least one class of equipment, comprising:
a computer-readable data storage medium in which a plurality of data records are stored, wherein each data record includes:
a first data field that stores data identifying a class of equipment,
a second data field that stores data identifying an attribute whose value is outputted by the class of equipment identified by the first field of that record, and
a third data field that stores data specifying an ID which the class of equipment identified by the first field of that record assigns to the attribute value identified by the second field of that record.
43. A data storage medium for storing data that describes one or more attributes of at least one class of equipment, comprising:
a computer-readable data storage medium in which a plurality of data records are stored, wherein each data record includes:
a first data field that stores data identifying a class of equipment,
a second data field that stores data identifying an attribute whose value is outputted by the class of equipment identified by the first field of that record, and
a third data field that stores data specifying a conversion parameter that defines the conversion of the value stored in the second field into physical units of measurement.
44. A computer-readable data storage medium in which is stored instructions executable by a computer to perform method steps for storing database records in a data storage device, wherein:
the method steps comprise the step of storing in a data storage device a plurality of attribute data records; and
said step of storing each attribute data record includes:
storing in that record a first field identifying a class of equipment,
storing in that record a second field identifying an attribute whose value is outputted by the class of equipment identified by the first field of that record, and
storing in that record a third field specifying an ID which the class of equipment identified by the first field of that record assigns to the attribute value identified by the second field of that record.
45. A computer-readable data storage medium in which is stored instructions executable by a computer to perform method steps for storing database records in a data storage device, wherein:
the method steps comprise the step of storing in a data storage device a plurality of attribute data records; and
said step of storing each attribute data record includes:
storing in that record a first field identifying a class of equipment,
storing in that record a second field identifying an attribute whose value is outputted by the class of equipment identified by the first field of that record, and
storing in that record a third field specifying a conversion parameter that defines a conversion of the value of the attribute identified in the second field into physical units of measurement.
Priority Applications (6)
Application Number | Priority Date | Filing Date | Title |
---|---|---|---|
US10/617,901 US20060167947A1 (en) | 2003-03-01 | 2003-07-10 | Communications interface database for electronic diagnostic apparatus |
JP2006508690A JP2007521545A (en) | 2003-03-01 | 2004-02-05 | Communication interface database for electronic diagnostic equipment |
PCT/US2004/003595 WO2004079465A1 (en) | 2003-03-01 | 2004-02-05 | Communications interface database for electronic diagnostic apparatus |
KR1020057016262A KR20050108374A (en) | 2003-03-01 | 2004-02-05 | Communications interface database for electronic diagnostic apparatus |
US11/904,857 US9026558B2 (en) | 2003-03-01 | 2007-09-28 | Communications interface database for electronic diagnostic apparatus |
JP2010251945A JP5372891B2 (en) | 2003-03-01 | 2010-11-10 | Communication interface database for electronic diagnostic equipment |
Applications Claiming Priority (2)
Application Number | Priority Date | Filing Date | Title |
---|---|---|---|
US45130103P | 2003-03-01 | 2003-03-01 | |
US10/617,901 US20060167947A1 (en) | 2003-03-01 | 2003-07-10 | Communications interface database for electronic diagnostic apparatus |
Related Child Applications (1)
Application Number | Title | Priority Date | Filing Date |
---|---|---|---|
US11/904,857 Continuation US9026558B2 (en) | 2003-03-01 | 2007-09-28 | Communications interface database for electronic diagnostic apparatus |
Publications (1)
Publication Number | Publication Date |
---|---|
US20060167947A1 true US20060167947A1 (en) | 2006-07-27 |
Family
ID=32965542
Family Applications (2)
Application Number | Title | Priority Date | Filing Date |
---|---|---|---|
US10/617,901 Abandoned US20060167947A1 (en) | 2003-03-01 | 2003-07-10 | Communications interface database for electronic diagnostic apparatus |
US11/904,857 Expired - Fee Related US9026558B2 (en) | 2003-03-01 | 2007-09-28 | Communications interface database for electronic diagnostic apparatus |
Family Applications After (1)
Application Number | Title | Priority Date | Filing Date |
---|---|---|---|
US11/904,857 Expired - Fee Related US9026558B2 (en) | 2003-03-01 | 2007-09-28 | Communications interface database for electronic diagnostic apparatus |
Country Status (4)
Country | Link |
---|---|
US (2) | US20060167947A1 (en) |
JP (2) | JP2007521545A (en) |
KR (1) | KR20050108374A (en) |
WO (1) | WO2004079465A1 (en) |
Cited By (16)
Publication number | Priority date | Publication date | Assignee | Title |
---|---|---|---|---|
US20040006506A1 (en) * | 2002-05-31 | 2004-01-08 | Khanh Hoang | System and method for integrating, managing and coordinating customer activities |
US20070214179A1 (en) * | 2006-03-10 | 2007-09-13 | Khanh Hoang | Searching, filtering, creating, displaying, and managing entity relationships across multiple data hierarchies through a user interface |
US20090024589A1 (en) * | 2007-07-20 | 2009-01-22 | Manish Sood | Methods and systems for accessing data |
US20090106596A1 (en) * | 2007-10-19 | 2009-04-23 | Oracle International Corporation | User-triggered diagnostic data gathering |
US20090125830A1 (en) * | 2007-11-13 | 2009-05-14 | Apple Inc. | Compound Fields |
US20090182780A1 (en) * | 2005-06-27 | 2009-07-16 | Stanley Wong | Method and apparatus for data integration and management |
US20090327347A1 (en) * | 2006-01-03 | 2009-12-31 | Khanh Hoang | Relationship data management |
US20100318847A1 (en) * | 2009-06-16 | 2010-12-16 | Oracle International Corporation | Techniques for building an aggregate model for performing diagnostics |
US20110153540A1 (en) * | 2009-12-17 | 2011-06-23 | Oracle International Corporation | Techniques for generating diagnostic results |
US8139840B1 (en) | 2008-04-10 | 2012-03-20 | Kla-Tencor Corporation | Inspection system and method for high-speed serial data transfer |
US8150887B1 (en) | 2007-12-21 | 2012-04-03 | Emc Corporation | Identifiers for non-searchable attributes |
US8171054B1 (en) | 2007-12-21 | 2012-05-01 | Emc Corporation | Optimized fetching for customization object attributes |
US8171006B1 (en) * | 2007-12-21 | 2012-05-01 | Emc Corporation | Retrieval of searchable and non-searchable attributes |
US8255426B1 (en) | 2007-12-21 | 2012-08-28 | Emc Corporation | Efficient storage of non-searchable attributes |
US11163807B2 (en) * | 2019-06-05 | 2021-11-02 | Premier Healthcare Solutions, Inc. | System for data structure clustering based on variation in data attribute performance |
US20230098023A1 (en) * | 2021-09-24 | 2023-03-30 | Sap Se | Plugin version management for legacy on-premise application |
Families Citing this family (8)
Publication number | Priority date | Publication date | Assignee | Title |
---|---|---|---|---|
US20060167947A1 (en) | 2003-03-01 | 2006-07-27 | Dunkle Mark V | Communications interface database for electronic diagnostic apparatus |
US8341151B2 (en) * | 2008-09-15 | 2012-12-25 | Margalit Mordehai | Method and system for providing targeted searching and browsing |
WO2014148176A1 (en) * | 2013-03-19 | 2014-09-25 | 株式会社smart-FOA | Information-gathering system, information-gathering method, and storage medium |
JP6235868B2 (en) * | 2013-10-31 | 2017-11-22 | 株式会社smart−FOA | Information collection system |
CN105573971B (en) * | 2014-10-10 | 2018-09-25 | 富士通株式会社 | Table reconfiguration device and method |
KR101704145B1 (en) * | 2014-12-30 | 2017-02-08 | 주식회사 포스코아이씨티 | Controller Management Station for Supporting Heterogeneous Database and Controlling System Including The Controller Management Station |
US20180189365A1 (en) * | 2017-01-04 | 2018-07-05 | Honeywell International Inc. | Combining manual and automated test results in an industrial facility |
CN108984550B (en) * | 2017-05-31 | 2022-08-26 | 西门子公司 | Method, device and system for determining signal rule of data to label data |
Citations (19)
Publication number | Priority date | Publication date | Assignee | Title |
---|---|---|---|---|
US4841456A (en) * | 1986-09-09 | 1989-06-20 | The Boeing Company | Test system and method using artificial intelligence control |
US5105438A (en) * | 1990-12-10 | 1992-04-14 | At&T Bell Laboratories | Remotely accessing intelligent network channel terminating equipment device |
US5528510A (en) * | 1991-03-01 | 1996-06-18 | Texas Instruments Incorporated | Equipment performance apparatus and method |
US5587930A (en) * | 1990-07-24 | 1996-12-24 | Mitsubishi Denki Kabushiki Kaisha | Fault diagnosis device |
US5668745A (en) * | 1995-10-20 | 1997-09-16 | Lsi Logic Corporation | Method and apparatus for testing of semiconductor devices |
US5777876A (en) * | 1995-12-29 | 1998-07-07 | Bull Hn Information Systems Inc. | Database manufacturing process management system |
US5778049A (en) * | 1996-06-26 | 1998-07-07 | Mci Communications Corporation | Service engineering template |
US6061685A (en) * | 1994-11-23 | 2000-05-09 | Telefonaktiebolaget Lm Ericsson | System and method for providing a managing system that manages a number of managed systems with information that is up-to-date |
US6070188A (en) * | 1995-12-28 | 2000-05-30 | Nokia Telecommunications Oy | Telecommunications network management system |
US6128588A (en) * | 1997-10-01 | 2000-10-03 | Sony Corporation | Integrated wafer fab time standard (machine tact) database |
US20010043568A1 (en) * | 1996-03-29 | 2001-11-22 | Mchale John F. | Communication server apparatus and method |
US20020105355A1 (en) * | 2000-10-13 | 2002-08-08 | John Floyd | Automated monitoring system, virtual oven and method for stress testing logically grouped modules |
US6470227B1 (en) * | 1997-12-02 | 2002-10-22 | Murali D. Rangachari | Method and apparatus for automating a microelectric manufacturing process |
US20030046027A1 (en) * | 2001-09-05 | 2003-03-06 | Mitsubishi Denki Kabushiki Kaisha | Monitoring system |
US6665662B1 (en) * | 2000-11-20 | 2003-12-16 | Cisco Technology, Inc. | Query translation system for retrieving business vocabulary terms |
US20030236628A1 (en) * | 2002-06-25 | 2003-12-25 | Martorana Richard T. | Environmentally mitigated navigation system |
US6697750B1 (en) * | 2001-01-11 | 2004-02-24 | Ciena Corporation | Method and apparatus for performing parallel asynchronous testing of optical modules |
US6820076B2 (en) * | 2000-05-18 | 2004-11-16 | I2 Technologies Us, Inc. | Database system facilitating parametric searching |
US20050271132A1 (en) * | 2003-12-18 | 2005-12-08 | Josh Kolenc | System and method for protection system design support |
Family Cites Families (22)
Publication number | Priority date | Publication date | Assignee | Title |
---|---|---|---|---|
US5745268A (en) * | 1995-06-07 | 1998-04-28 | Toshiba America Medical Systems, Inc. | Vascular portable assistant computer system |
US5715241A (en) * | 1996-05-13 | 1998-02-03 | Adtran, Inc. | ISDN terminal equipment-resident mechanism for determining service profile identifiers and associated telecommunication switch protocol |
JPH10304008A (en) | 1997-02-25 | 1998-11-13 | Jeol Ltd | Data management system |
US6134674A (en) * | 1997-02-28 | 2000-10-17 | Sony Corporation | Computer based test operating system |
US5918191A (en) * | 1997-03-11 | 1999-06-29 | Certified Measurements, Inc. | System and method for managing data for an equipment calibration laboratory |
US5953684A (en) * | 1997-03-17 | 1999-09-14 | Hewlett-Packard Company | Methods and apparatus for integrated storage of test environment context information |
US5845234A (en) * | 1997-04-22 | 1998-12-01 | Integrated Measurement Systems, Inc. | System and method for efficiently generating testing program code for use in automatic test equipment |
US6034000A (en) * | 1997-07-28 | 2000-03-07 | Applied Materials, Inc. | Multiple loadlock system |
US6047293A (en) * | 1997-09-16 | 2000-04-04 | Teradyne, Inc. | System for storing and searching named device parameter data in a test system for testing an integrated circuit |
US6535779B1 (en) * | 1998-03-06 | 2003-03-18 | Applied Materials, Inc. | Apparatus and method for endpoint control and plasma monitoring |
EP1125314A1 (en) * | 1998-07-10 | 2001-08-22 | Applied Materials, Inc. | Improved endpoint detection for substrate fabrication processes |
US20010047283A1 (en) * | 2000-02-01 | 2001-11-29 | Melick Bruce D. | Electronic system for identification, recording, storing, and retrieving material handling equipment records and certifications |
US7734287B2 (en) * | 2000-04-10 | 2010-06-08 | I/O Controls Corporation | System for providing remote access to diagnostic information over a wide area network |
US6952656B1 (en) * | 2000-04-28 | 2005-10-04 | Applied Materials, Inc. | Wafer fabrication data acquisition and management systems |
KR20020022530A (en) * | 2000-09-20 | 2002-03-27 | 가나이 쓰도무 | Remote diagnosis system and method for semiconductor manufacturing apparatus |
US6980959B1 (en) * | 2000-10-17 | 2005-12-27 | Accenture Llp | Configuring mechanical equipment |
US6725180B2 (en) * | 2001-01-12 | 2004-04-20 | Ingersoll-Rand Company | Environmental monitoring system |
US6801817B1 (en) * | 2001-02-20 | 2004-10-05 | Advanced Micro Devices, Inc. | Method and apparatus for integrating multiple process controllers |
JP3993396B2 (en) * | 2001-03-30 | 2007-10-17 | 株式会社東芝 | Manufacturing method of semiconductor device |
US7191184B2 (en) * | 2001-05-02 | 2007-03-13 | National Instruments Corporation | Optimized storage for measurement data |
AU2003270624A1 (en) * | 2002-09-13 | 2004-04-30 | Curtis V. Casto | Calibration process management system and method |
US20060167947A1 (en) | 2003-03-01 | 2006-07-27 | Dunkle Mark V | Communications interface database for electronic diagnostic apparatus |
-
2003
- 2003-07-10 US US10/617,901 patent/US20060167947A1/en not_active Abandoned
-
2004
- 2004-02-05 KR KR1020057016262A patent/KR20050108374A/en not_active Application Discontinuation
- 2004-02-05 JP JP2006508690A patent/JP2007521545A/en active Pending
- 2004-02-05 WO PCT/US2004/003595 patent/WO2004079465A1/en active Application Filing
-
2007
- 2007-09-28 US US11/904,857 patent/US9026558B2/en not_active Expired - Fee Related
-
2010
- 2010-11-10 JP JP2010251945A patent/JP5372891B2/en not_active Expired - Fee Related
Patent Citations (20)
Publication number | Priority date | Publication date | Assignee | Title |
---|---|---|---|---|
US4841456A (en) * | 1986-09-09 | 1989-06-20 | The Boeing Company | Test system and method using artificial intelligence control |
US5587930A (en) * | 1990-07-24 | 1996-12-24 | Mitsubishi Denki Kabushiki Kaisha | Fault diagnosis device |
US5105438A (en) * | 1990-12-10 | 1992-04-14 | At&T Bell Laboratories | Remotely accessing intelligent network channel terminating equipment device |
US5528510A (en) * | 1991-03-01 | 1996-06-18 | Texas Instruments Incorporated | Equipment performance apparatus and method |
US6061685A (en) * | 1994-11-23 | 2000-05-09 | Telefonaktiebolaget Lm Ericsson | System and method for providing a managing system that manages a number of managed systems with information that is up-to-date |
US5668745A (en) * | 1995-10-20 | 1997-09-16 | Lsi Logic Corporation | Method and apparatus for testing of semiconductor devices |
US6070188A (en) * | 1995-12-28 | 2000-05-30 | Nokia Telecommunications Oy | Telecommunications network management system |
US5777876A (en) * | 1995-12-29 | 1998-07-07 | Bull Hn Information Systems Inc. | Database manufacturing process management system |
US20010043568A1 (en) * | 1996-03-29 | 2001-11-22 | Mchale John F. | Communication server apparatus and method |
US5778049A (en) * | 1996-06-26 | 1998-07-07 | Mci Communications Corporation | Service engineering template |
US6128588A (en) * | 1997-10-01 | 2000-10-03 | Sony Corporation | Integrated wafer fab time standard (machine tact) database |
US6470227B1 (en) * | 1997-12-02 | 2002-10-22 | Murali D. Rangachari | Method and apparatus for automating a microelectric manufacturing process |
US6820076B2 (en) * | 2000-05-18 | 2004-11-16 | I2 Technologies Us, Inc. | Database system facilitating parametric searching |
US20020105355A1 (en) * | 2000-10-13 | 2002-08-08 | John Floyd | Automated monitoring system, virtual oven and method for stress testing logically grouped modules |
US20020107581A1 (en) * | 2000-10-13 | 2002-08-08 | Ciena Corporation | Stress-test information database structure and method of use |
US6665662B1 (en) * | 2000-11-20 | 2003-12-16 | Cisco Technology, Inc. | Query translation system for retrieving business vocabulary terms |
US6697750B1 (en) * | 2001-01-11 | 2004-02-24 | Ciena Corporation | Method and apparatus for performing parallel asynchronous testing of optical modules |
US20030046027A1 (en) * | 2001-09-05 | 2003-03-06 | Mitsubishi Denki Kabushiki Kaisha | Monitoring system |
US20030236628A1 (en) * | 2002-06-25 | 2003-12-25 | Martorana Richard T. | Environmentally mitigated navigation system |
US20050271132A1 (en) * | 2003-12-18 | 2005-12-08 | Josh Kolenc | System and method for protection system design support |
Cited By (35)
Publication number | Priority date | Publication date | Assignee | Title |
---|---|---|---|---|
US8583680B2 (en) | 2002-05-31 | 2013-11-12 | Informatica Corporation | System and method for integrating, managing and coordinating customer activities |
US20040006506A1 (en) * | 2002-05-31 | 2004-01-08 | Khanh Hoang | System and method for integrating, managing and coordinating customer activities |
US8200622B2 (en) | 2002-05-31 | 2012-06-12 | Informatica Corporation | System and method for integrating, managing and coordinating customer activities |
US8166048B2 (en) * | 2005-06-27 | 2012-04-24 | Informatica Corporation | Method and apparatus for data integration and management |
US20090182780A1 (en) * | 2005-06-27 | 2009-07-16 | Stanley Wong | Method and apparatus for data integration and management |
US8392460B2 (en) | 2006-01-03 | 2013-03-05 | Informatica Corporation | Relationship data management |
US20090327347A1 (en) * | 2006-01-03 | 2009-12-31 | Khanh Hoang | Relationship data management |
US8065266B2 (en) | 2006-01-03 | 2011-11-22 | Informatica Corporation | Relationship data management |
US20070214179A1 (en) * | 2006-03-10 | 2007-09-13 | Khanh Hoang | Searching, filtering, creating, displaying, and managing entity relationships across multiple data hierarchies through a user interface |
US20090024589A1 (en) * | 2007-07-20 | 2009-01-22 | Manish Sood | Methods and systems for accessing data |
US8271477B2 (en) | 2007-07-20 | 2012-09-18 | Informatica Corporation | Methods and systems for accessing data |
US8429467B2 (en) | 2007-10-19 | 2013-04-23 | Oracle International Corporation | User-triggered diagnostic data gathering |
US8688700B2 (en) * | 2007-10-19 | 2014-04-01 | Oracle International Corporation | Scrubbing and editing of diagnostic data |
US20090106596A1 (en) * | 2007-10-19 | 2009-04-23 | Oracle International Corporation | User-triggered diagnostic data gathering |
US20090106262A1 (en) * | 2007-10-19 | 2009-04-23 | Oracle International Corporation | Scrubbing and editing of diagnostic data |
US20090125830A1 (en) * | 2007-11-13 | 2009-05-14 | Apple Inc. | Compound Fields |
US20120185504A1 (en) * | 2007-12-21 | 2012-07-19 | Emc Corporation | Retrieval of searchable and non-searchable attributes |
US20130179463A1 (en) * | 2007-12-21 | 2013-07-11 | Shu-Shang Sam Wei | Retrieval of searchable and non-searchable attributes |
US8255426B1 (en) | 2007-12-21 | 2012-08-28 | Emc Corporation | Efficient storage of non-searchable attributes |
US8949282B1 (en) * | 2007-12-21 | 2015-02-03 | Emc Corporation | Efficient storage of non-searchable attributes |
US20120290623A1 (en) * | 2007-12-21 | 2012-11-15 | Emc Corporation | Efficient storage of non-searchable attributes |
US8375015B2 (en) * | 2007-12-21 | 2013-02-12 | Emc Corporation | Retrieval of searchable and non-searchable attributes |
US8930336B2 (en) * | 2007-12-21 | 2015-01-06 | Emc Corporation | Retrieval of searchable and non-searchable attributes |
US8595265B2 (en) * | 2007-12-21 | 2013-11-26 | Emc Corporation | Efficient storage of non-searchable attributes |
US8171006B1 (en) * | 2007-12-21 | 2012-05-01 | Emc Corporation | Retrieval of searchable and non-searchable attributes |
US8150887B1 (en) | 2007-12-21 | 2012-04-03 | Emc Corporation | Identifiers for non-searchable attributes |
US8171054B1 (en) | 2007-12-21 | 2012-05-01 | Emc Corporation | Optimized fetching for customization object attributes |
US8139840B1 (en) | 2008-04-10 | 2012-03-20 | Kla-Tencor Corporation | Inspection system and method for high-speed serial data transfer |
US8417656B2 (en) | 2009-06-16 | 2013-04-09 | Oracle International Corporation | Techniques for building an aggregate model for performing diagnostics |
US20100318847A1 (en) * | 2009-06-16 | 2010-12-16 | Oracle International Corporation | Techniques for building an aggregate model for performing diagnostics |
US8612377B2 (en) | 2009-12-17 | 2013-12-17 | Oracle International Corporation | Techniques for generating diagnostic results |
US20110153540A1 (en) * | 2009-12-17 | 2011-06-23 | Oracle International Corporation | Techniques for generating diagnostic results |
US11163807B2 (en) * | 2019-06-05 | 2021-11-02 | Premier Healthcare Solutions, Inc. | System for data structure clustering based on variation in data attribute performance |
US11681730B2 (en) | 2019-06-05 | 2023-06-20 | Premier Healthcare Solutions, Inc. | System for data structure clustering based on variation in data attribute performance |
US20230098023A1 (en) * | 2021-09-24 | 2023-03-30 | Sap Se | Plugin version management for legacy on-premise application |
Also Published As
Publication number | Publication date |
---|---|
KR20050108374A (en) | 2005-11-16 |
JP2007521545A (en) | 2007-08-02 |
JP2011101023A (en) | 2011-05-19 |
US9026558B2 (en) | 2015-05-05 |
WO2004079465A1 (en) | 2004-09-16 |
US20080126423A1 (en) | 2008-05-29 |
JP5372891B2 (en) | 2013-12-18 |
Similar Documents
Publication | Publication Date | Title |
---|---|---|
US9026558B2 (en) | Communications interface database for electronic diagnostic apparatus | |
JP2007521545A6 (en) | Communication interface database for electronic diagnostic equipment | |
KR100477301B1 (en) | Process monitoring system for lithography lasers | |
US6952656B1 (en) | Wafer fabrication data acquisition and management systems | |
US7113883B1 (en) | Test configuration and data management system and associated method for enterprise test operations | |
US7693687B2 (en) | Controller and method to mediate data collection from smart sensors for fab applications | |
EP1224513B1 (en) | Improved interface for managing process calibrators | |
JP4685446B2 (en) | How to process data based on the data context | |
US20050268171A1 (en) | Enterprise test data management system utilizing hierarchical test data models and related methods | |
US20050246390A1 (en) | Enterprise test data management system utilizing automatically created test data structures and related methods | |
JP2005531933A (en) | Method for dynamic sensor construction and runtime execution | |
KR20050061498A (en) | Method and apparatus for the monitoring and control of a semiconductor manufacturing process | |
US11500573B2 (en) | Multiple interface data exchange application for use in process control | |
WO2013008476A1 (en) | Dynamic infrastructure administration system | |
US6606582B1 (en) | Universal system, method and computer program product for collecting and processing process data including particle measurement data | |
US20050228765A1 (en) | Mechanism for synchronizing manafacturing information systems and document content management systems data | |
TW202044056A (en) | Data capture and transformation to support data analysis and machine learning for substrate manufacturing systems | |
Copp et al. | Towards the automation of water quality monitoring networks | |
US20030120446A1 (en) | Net system and method for quality control | |
US20050060282A1 (en) | Patent family downloading system and method using selected downloading object | |
US6694210B1 (en) | Process recipe modification in an integrated circuit fabrication apparatus | |
US7315851B2 (en) | Methods for creating control charts using a computer system | |
CN100445912C (en) | Communications interface database for electronic diagnostic apparatus | |
TW200817891A (en) | Adaptive multivariate fault detection | |
US6925343B2 (en) | Flow conversion system for a manufacturing process, method for converting a process flow, system for controlling manufacturing process, method for controlling a manufacturing process and a computer program product |
Legal Events
Date | Code | Title | Description |
---|---|---|---|
AS | Assignment |
Owner name: APPLIED MATERIALS, INC., CALIFORNIA Free format text: ASSIGNMENT OF ASSIGNORS INTEREST;ASSIGNOR:DUNKLE, MARK VANDEVERT;REEL/FRAME:014283/0980 Effective date: 20030707 |
|
STCB | Information on status: application discontinuation |
Free format text: ABANDONED -- FAILURE TO RESPOND TO AN OFFICE ACTION |