U.S. patent application number 10/617901 was filed with the patent office on 2006-07-27 for communications interface database for electronic diagnostic apparatus.
Invention is credited to Mark Vandevert Dunkle.
Application Number | 20060167947 10/617901 |
Document ID | / |
Family ID | 32965542 |
Filed Date | 2006-07-27 |
United States Patent
Application |
20060167947 |
Kind Code |
A1 |
Dunkle; Mark Vandevert |
July 27, 2006 |
Communications interface database for electronic diagnostic
apparatus
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.
Inventors: |
Dunkle; Mark Vandevert;
(Campbell, CA) |
Correspondence
Address: |
Patent Counsel;Applied Materials, Inc.
P.O. Box 450-A
Santa Clara
CA
95052
US
|
Family ID: |
32965542 |
Appl. No.: |
10/617901 |
Filed: |
July 10, 2003 |
Related U.S. Patent Documents
|
|
|
|
|
|
Application
Number |
Filing Date |
Patent Number |
|
|
60451301 |
Mar 1, 2003 |
|
|
|
Current U.S.
Class: |
1/1 ;
707/999.2 |
Current CPC
Class: |
Y02P 90/10 20151101;
Y02P 90/02 20151101; Y02P 90/80 20151101; G05B 2219/31323 20130101;
Y02P 90/24 20151101; G05B 19/4183 20130101; Y02P 90/86
20151101 |
Class at
Publication: |
707/200 |
International
Class: |
G06F 12/00 20060101
G06F012/00; G06F 17/30 20060101 G06F017/30 |
Claims
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.
Description
CROSS REFERENCE TO RELATED APPLICATION
[0001] This patent application claims the benefit under 35 USC
119(e) of U.S. provisional application No. 60/451,301 filed Mar. 1,
2003.
FIELD OF THE INVENTION
[0002] 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.
BACKGROUND OF THE INVENTION
[0003] 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.
[0004] 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.
[0005] 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.
[0006] 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.
SUMMARY OF THE INVENTION
[0007] 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.
[0008] 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.
[0009] 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;
[0010] 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.
[0011] 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.
[0012] 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.
[0013] 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.
BRIEF DESCRIPTION OF THE DRAWINGS
[0014] 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.
[0015] 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.
[0016] 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.
[0017] FIG. 4 is a schematic diagram of two attribute records which
can represent the same information as the three records of FIG.
3.
[0018] FIG. 5 is a schematic diagram of a system in which the
attribute database is remote from the diagnostic apparatus.
[0019] 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.
[0020] FIG. 7 is a database table representing the attribute
database having the fields shown in FIG. 2.
[0021] FIG. 8 is a database table showing the database of FIG. 7
divided into two tables.
DETAILED DESCRIPTION OF THE PREFERRED EMBODIMENTS
Conventional UUT and Diagnostic Apparatus
[0022] Before describing the novel diagnostic apparatus and
database, it will be helpful to describe how UUT's generally
communicate with conventional diagnostic apparatuses.
[0023] 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, three chambers 21, 22, 23 can be plasma
chemical vapor deposition (CVD) chambers, one chamber 24 can be a
heating chamber, and two chambers 25 and 26 can be plasma etch
chambers.
[0024] (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.)
[0025] One of the functions of the UUT mainframe 12 is to provide a
central communications interface or communications bus 31 for the
chambers. Each chamber has a data port 32 connected to a
corresponding internal data port 33 of the mainframe. The
mainframe's internal data ports 33 may all be connected to a common
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.
[0026] 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 additional internal data ports 52 to receive measurement
values from the measurement instruments and to send commands for
controlling the measurement instruments.
[0027] 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 the UUT 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 the
measurement 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".
[0028] 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 a digital interface 14 such as
a conventional RS-232 serial port or a conventional Ethernet port.
The UUT also may have one or more analog communications interfaces
15, typically for the purpose of outputting measurement values from
measurement instruments 50 that produce analog output signals
52.
[0029] 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 a digital communications interface 18 and one or more
analog communications interfaces 17 respectively connected to the
UUT's digital interface 14 and analog interfaces 15. (For purposes
of illustration, the UUT in FIG. 1 includes analog interfaces,
whereas the commercially sold Precision 5000 mainframe does not
include an analog interface.)
[0030] 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, the diagnostic apparatus 10 may
include additional communications interfaces 19 connected to the
communications interfaces 54 of the chambers and measurement
instruments.
[0031] 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.
[0032] 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.
[0033] 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 14 or 54 of the data source a "read" command that
includes the ID of that attribute. The ID, also called a logical
address or logical port, is a digital value by which a UUT, or its
associated attribute data source, uniquely identifies each
attribute it is capable of outputting. By "logical" we mean that
the ID need not correspond to any physical address or physical
port.
[0034] Besides responding to "read" commands, some attribute data
sources also respond to "write" commands via the digital I/O
interface 14 or 54. For example, a diagnostic apparatus or factory
controller computer can send commands to the UUT that change the
operating parameters of the chambers.
[0035] 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 14 or 54. The attribute data typically is
formatted as periodically transmitted frames, where each frame of
data contains the current value of every attribute. In some data
source apparatuses, each attribute is identified simply by its
sequential position or offset in the frame. In that case, the ID or
logical address of each attribute would be its position or offset.
In other data sources, the frame may include an ID field associated
with each attribute field. The ID value transmitted in the ID field
identifies the attribute whose value is transmitted in the
associated attribute field.
[0036] 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.
[0037] 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.
[0038] 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.
[0039] 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.
[0040] 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 the first chamber 21 and
the chamber pressure in the second chamber 22 would be
distinguished by having different ID's.
[0041] 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.
[0042] 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.
[0043] 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.
[0044] 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.
[0045] 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
[0046] My novel diagnostic apparatus 10 adds to the conventional
diagnostic apparatus described above a novel database containing
communications interface specifications enabling the diagnostic
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.
[0047] 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.
[0048] 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".)
[0049] 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".
[0050] 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.
[0051] 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
[0052] 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.
[0053] 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.
[0054] 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.
[0055] 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
[0056] 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.
[0057] For classes of UUT's that are mainframes 12 designed to
connect to multiple chambers 21-26 as shown in FIG. 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.
[0058] 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.
[0059] 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.
[0060] For example, one model of mainframe 12 may be capable of
attachment to up to six process chambers as shown in FIG. 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 in chamber 1", "pressure in chamber 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 the values 1 through 6 in the
"Chamber Position" field and has the corresponding one of the six
ID's in the "ID" field.
[0061] 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," the
mainframe UUT 12 shown in FIG. 1 can be connected to several
different types of chambers, such as plasma CVD chambers 21-23,
heating chamber 24, and plasma etch chambers 25, 26. Furthermore, a
given chamber type generally may be available in several different
models. For example, Applied Materials commercially sells different
models of plasma etch chambers under the model names "MxP", "MxP+",
and "Super-e". The "Chamber Model" field should store sufficient
information to identify the chamber type and model, such as "MxP
Etch".
[0062] 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.
[0063] 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.
[0064] 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.
[0065] 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
[0066] As shown in FIG. 2, each attribute record preferably
includes an "Interface & Protocol" field. If the UUT has more
than one external 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.
[0067] 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.
[0068] 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.
[0069] 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.
[0070] 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
[0071] 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.
[0072] 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.
[0073] 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.
[0074] 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.
[0075] 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
[0076] As explained above, a UUT 12 has at least one external
communications interface 14 through which it outputs attribute
data. The diagnostic apparatus 10 should have a communications
interface 18 compatible with, and connected to, the external
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.
[0077] If the UUT 12 is a conventional semiconductor fabrication
tool or mainframe, its external 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. A diagnostic 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, the diagnostic apparatus
10 can include a computer 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 of computer 62 commonly has an RS-232 serial 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 conventional computer 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.
[0078] 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.
[0079] 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 a programmable computer
62.
[0080] 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 a conventional 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.
[0081] That attribute database and the DBMS software can be
installed on the data storage device 60 and the computer 62 within
the diagnostic apparatus 10 shown in FIG. 1. Both the DBMS software
and the previously described data collection and analysis software
can be installed and simultaneously running on the same computer
62.
[0082] More preferably, as shown in FIG. 5, the attribute database
and the DBMS software can be installed on a data storage device 64
and a server computer 66 at a remote location. The diagnostic
apparatus 10 can connect to the server 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 the server computer 66
preferably has multi-user server capability so that many diagnostic
apparatuses 10 at different locations can simultaneously access the
database.
[0083] 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. Portable diagnostic 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 a communications link 68.
[0084] If the attribute database is installed on a remotely located
64 and server computer 66 as shown in FIG. 5, then each diagnostic
apparatus 10 should include a computer 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 the server computer 66 whenever the diagnostic apparatus
needs to retrieve a database record, such as to determine the ID or
other properties of an attribute. The computer 62 within each
diagnostic apparatus 10 also should include the previously
described conventional software for communicating with the UUT to
retrieve attribute data.
Operation
[0085] 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.
[0086] FIG. 6 is a flow chart showing the steps by which a
diagnostic apparatus 10 retrieves attribute data from a UUT using
the previously described attribute database. These steps preferably
are implemented by straightforward programming of the computer 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 the same computer 62 within the diagnostic 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.
[0087] 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.
[0088] Step 602: Optionally, if the attribute database is stored on
a remote server 66, the diagnostic apparatus can transfer from the
server's storage 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 in Step 601. This optional 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
this Step 602. This step is accomplished by a database client
software on the local computer 62 sending a query to DBMS server
software on the server computer 66.
[0089] 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."
[0090] 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
in Step 601 and the selected attribute. If optional Step 602 was
performed, the diagnostic apparatus can search the attribute
records transferred to its local storage device in Step 602 to find
the one attribute record whose "Attribute" field matches the
selected attribute. Otherwise, conventional database client
software on the local computer 62 should send a query to DBMS
server software on the server computer 66 to retrieve the one
attribute record whose "UUT Class" field matches the UUT class
identified in Step 601 and whose "Attribute" field matches the
selected attribute.
[0091] 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.
[0092] 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".
[0093] 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, the diagnostic 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.
[0094] Preferably, the computer 62 of the diagnostic apparatus
includes conventional data collection software as described under
the heading "Hardware Implementation". If so, in Step 606 the
Attribute Look-Up software preferably passes the ID, the interface
information, and the protocol information obtained in Step 605 to
the data collection software, which employs the specified
communications protocol to retrieve the attribute data from the
UUT.
[0095] 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
[0096] 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".
[0097] 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 2.sup.N-1, where the binary values of zero and
2.sup.N-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 2.sup.N-1,
respectively. The value stored in the "Units" field designates the
physical units in which such physical attribute values are
expressed.
[0098] 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.degree. C. to 550.degree. C. Accordingly, the mainframe should
output binary values in the range of zero to 2N-1 to represent
temperatures in the range of 50.degree. C. to 550.degree. 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
[0099] 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.
[0100] 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.
[0101] 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.
[0102] 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.
[0103] 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.
[0104] 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.
[0105] 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 to logical 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 to logical port 33 again. As shown in FIG.
3, these revisions can be represented by three database records
instead of twenty.
[0106] 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 in Chamber 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 in FIG. 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".
[0107] Although versions conventionally are identified by version
numbers, non-numeric names also can be used to identify different
versions.
[0108] 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 in FIG. 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
[0109] FIG. 2, discussed extensively above, depicts the fields in a
record of the attribute database. The identical database structure
is depicted in FIG. 7 in the form of a table. In the database
tables shown in FIGS. 7 and 8, the notation "A:B" for a field name
represents the sub-field named "B" of the compound field named
"A".
[0110] 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.
[0111] 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.
[0112] 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.
[0113] 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.
[0114] 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.
* * * * *