Dynamically Configurable Equipment Integration Architecture

The present invention generally relates to Data Communications, and more specifically to data communications between a host computer and factory equipment in a Computer Integrated Manufacturing (CIM) environment.

The primary standards for communications with semiconductor manufacturing machines come from the Semiconductor Equipment and Materials International (SEMI) and are titled "SEMI Equipment Communications Standard Part I" (SECS-I) and "SEMI Equipment Communications Standard Part II" (SECS-II). SECS-I is a layered protocol between factory equipment interface servers and host computers. SECS-II defines the details of the interpretation of messages exchanged between intelligent equipment and a host.

Requiring that equipment vendors comply with the SEMI standards is a good first step in implementing CIM Equipment Integration (EI). However, different types of manufacturing equipment have different requirements. Different vendors of similar equipment may likewise make different facilities available. The result is that much of the critical SECS-II communications host code has to be rewritten for each different type of equipment from each different manufacturer.

Current practice has been to develop EI system components targeted at specific equipment in specific CIM environments. Code reuse is achieved only in the form of code templates that are used as the starting point for customization. The output of this process is vulnerable to changes in the CIM system requirements or equipment interface specifications often requiring time-consuming rework.

A recent SEMATECH Equipment Interface Development (EID) project monthly report cited the average development time for a single component of many to be approximately 130-220 man-hours. This development time can be reduced to 45 man-hours using a combination of code templates and the SEMATECH proposed Automated Equipment Interface (AEI) SECS message set. Reducing time-to-market and cycle time require that this development time be further reduced.

In accordance with the invention, a dynamically configurable equipment integration architecture automatically records on a Host Computer statistics from operation of factory equipment received from a GEM Interface Server. The format of relevant messages containing selected reports are described in a Configuration File. Reports are enabled by execution of a Sampling Plan. Messages containing the selected reports received from the GEM Interface Server are translated into a Script utilizing the Configuration File. Interpreting the Script causes statistics contained in the reports to be written to an Output File stored on Secondary Storage on the Host Computer.

These and other features, and advantages, will be more clearly understood from the following detailed description taken in conjunction with the accompanying drawings. It is important to point out that there may be other embodiments of the present invention which are not specifically illustrated.

FIG. 1 is a block diagram showing the major hardware components of the invention, in accordance with the present invention;

FIG. 2 is a block diagram of a General Purpose Computer used as a Host Computer in FIG. 1.;

FIG. 3 is a block diagram showing information and file flow between the major components of a preferred embodiment of the invention operating in the Host Computer shown in FIG. 2; and

FIGS. 4 through 15 are flow charts illustrating one embodiment of the operation of the invention when a collection event message is received from a GEM Interface Server.

Computer Integrated Manufacturing (CIM) is becoming more dependent upon Equipment Integration (EI) every day. In the semiconductor manufacturing arena, manufacturers are requiring that any plant manufacturing equipment they purchase be capable of communicating utilizing standardized formats.

The primary standard for communications with semiconductor manufacturing machines comes from the Semiconductor Equipment and Materials International (SEMI) with international headquarters in Mountain View, Calif. The first level of protocols is titled "SEMI Equipment Communications Standard Part I" (SECS-I), SEMI E4-91. This is a layered protocol that defines a communications interface suitable for the exchange of messages between semiconductor processing equipment and a host. Semiconductor processing equipment includes equipment intended for wafer manufacturing, assembly, and packaging. A host is a computer or network of computers which exchange information with the equipment to accomplish manufacturing.

The SECS-I standard includes the description of the physical connector, signal levels, data rate and logical protocols required to exchange messages between the host and equipment over a serial point-to-point data path. It does not define the data within the message.

The "SEMI Equipment Communications Standard Part 2" (SECS-II), SEMI E5-94, defines the details of the interpretation of messages exchanged between intelligent equipment and a host. The SECS-II specification was developed in cooperation between SEMI and the Japan Electronic Industry Development Association Committee 12 on Equipment Communications.

SECS-II defines standard support for the most typical activities required for Integrated Circuit (IC) manufacturing. It also provides for the definition of equipment-specific messages to support those activities not covered by standard messages. While certain activities can be handled by common software in the host, it was expected that equipment-specific host software would be required to support the full capabilities of specific equipment.

SEMI also publishes a Generic Equipment Model ("GEM") specification, SEMI E30-94. GEM defines a standard implementation of SECS-II for all semiconductor manufacturing equipment. The GEM standard defines a common set of equipment behavior and communications capabilities that provide the functionality and flexibility to support the manufacturing automation programs of semiconductor device manufacturers.

The current definitions of SECS-I, SECS-II, and GEM are included in "Equipment Automation/Software Volume 1" and in "Equipment Automation/Software Volume II" available from SEMI at any of its primary locations including its International Headquarters at 805 East Middlefield Road, Mountain View, Calif. 94043-4080 USA, both volumes included herein by reference.

Requiring that equipment vendors comply with the SEMI standards is a good first step in implementing CIM Equipment Integration (EI). However, different types of manufacturing equipment have different requirements. Different vendors of similar equipment may likewise make different facilities available. The result is that much of the critical SECS-II communications host code has to be rewritten for each different type of equipment from each different manufacturer.

Current practice has been to develop EI system components targeted at specific equipment in specific CIM environments. Code reuse is achieved only in the form of code templates that are used as the starting point for customization. The output of this process is vulnerable to changes in the CIM system requirements or equipment interface specifications often requiring time-consuming rework.

A recent SEMATECH Equipment Interface Development (EID) project monthly report cited the average development time for a Virtual Factory Equipment Interface (VFEI) driver to be 130-220 man-hours. A VFEI driver is only one component of an E1 system. The development time can be reduced to 45 man-hours using a combination of code templates and the SEMATECH proposed Automated Equipment Interface (AEI) SECS message set. In furtherance of Motorola's 10x cycle time reduction initiative, this invention caused the development time to be brought down to approximately 4 hours.

The main function of manufacturing equipment in a factory is to perform the physical processing on the material. It is responsible for the collection and notification of data, alarm, and event information. It may also provide remote methods for allowing external control of the process definition through either equipment settings or recipes and process execution through remote commands.

Equipment Integration (EI) servers provide the software interface to the functionality offered by the equipment. The servers are an integral part of a larger CIM system. A good EI architecture should provide the CIM system with a consistent abstract interface for performing high level manufacturing functions.

The server functions should be at the semantic level of "Start Job" or "Stop Job". "Start Job" may require the server to complete some transaction with another factory system. For example, it may have to communicate with a recipe management system. If "Start Job" specifies a batch of many lots, the equipment server may do the individual lot scheduling and routing. Similar equipment specific behavior is necessary to support cluster tools.

Separating factory specific behaviors from equipment specific behaviors enables reuses of the equipment specific components in other factory environments. This separation also minimizes the change required to the EI server if factory system policies change over time.

Factory and equipment behaviors should also be clearly separated from the communication mechanism via a defined interface. SEMATECH's Virtual Factory Equipment Interface (VFED provides such an interface.

This invention includes translation of SECS-II encoded information. A more detailed description of the SECS-II protocol is helpful in understanding the invention.

A SECS-II message is a number of binary coded blocks of information. Each block contains a header and a data section composed of self-describing data items. Each data item is defined by its type, length, and value. The standard defines a number of data item types. One of the most important types is a recursive list structure allowing the definition of arbitrary complex data structure. This arbitrary complexity contributes significantly to the problem outlined above.

All the standard SECS-II messages are defined as structures of data items that can include equipment specific data items determined by their respective equipment vendors. A compatible server would need to have knowledge of the equipment specific data items' types and names. A data item's position in a data structure may also provide important information.

All information transmitted according to the SECS-II standard is formatted using two data structures: items and lists. These data structures define the logical divisions of the message, as distinct from the physical division of the message transfer protocol.

An item is an information packet which has a length and a format defined by the first 2, 3, or 4 bytes of the item. These first 2, 3, or 4 bytes are the item header (IH). The IH consists of the format byte and the length byte(s) as shown in Table T-1. Bits 1 and 2 of the IH are the Number of Length Bytes (NLB) in the IH. The Item Length (IL) refers to the number of bytes following the Item Header (IH) that constitutes the Item Body (IB), which is the actual data of the item. The IL refers only to the length of the IB, and does not include the IH.

All bytes in a given Item Body (IB) will be in the Item Format determined by the Item Format Code in the Item Header Table. Table T-2 illustrates the SECS-II Item Format Codes:

Fourteen of the fifteen Item Format Codes define formats used for groups of data that have the same representation in order to save repeated item headers. Thus a six byte Item Length combined with a 2 byte unsigned integer format (52 Octal) contains three 2 byte integers. Signed integers are two's complement, and floating point numbers correspond to IEEE standard 754.

The fifteenth format is the list. A list is an ordered set of elements, where an element can be either an item or a list. The list header (LH) has the same form as the Item Header (IH) with a format type of zero (0). However, the length bytes refer to the number of elements in the list, rather than to the number of bytes. The list structure allows the grouping of items of related information which may have different formats into useful structures. The recursive aspect of the definition allows for arbitrarily complex data structures.

As noted above, the SECS-II protocol is described more fully in "Equipment Automation/Software Volume 1". Examples are given therein of protocol encoding. The manual also includes a large number of predefined messages.

The remainder of this description will discuss the preferred embodiment of the invention. FIG. 1 is a block diagram showing the major hardware components. A CIM application running in a Host Computer 10 communicates with Factory Equipment 18 across communications line 11, router 12, backbone 14, communications lines 15 and through SEMI GEM compliant Interface Servers 16. Usually, the GEM Interface Servers 16 are general purpose computers provided by the Equipment 18 manufacturers. However, they may be integrated into the Factory Equipment 18. The hardware and software protocols between the GEM Interface Servers 16 and the Host Computer 10 are SECS-I and SECS-II.

In the preferred embodiment, the communications lines 11, 15, and backbone 14 are high speed local area network (LANs) links. However, these elements may alternatively comprise any functional equivalent, including twisted pair, fiber optic, wireless LAN and the like. Note also that router 12 and backbone 14 are not necessary for the operation of the invention, but are preferably included to enhance communications performance.

FIG. 2 is a block diagram of a General Purpose Computer 20 used as a Host Computer 10 in FIG. 1. The General Purpose Computer 20 has a Computer Processor 22 often connected via a Bus 26 with Memory 24. Also attached to the Computer 20 are Secondary Storage 30, External Storage 32, a monitor 34, keyboard 36, and printer 38. The External Storage 32 may be diskettes, CD-ROM, tape, or even another computer. Computer Programs 33 including the Equipment Integration server utilized in this invention can be loaded from the External Storage media 32 either directly into Memory 24 for execution, or staged first to Secondary Storage 32.

FIG. 3 is a block diagram showing information and file flow between the major components of the invention operating in the Host Computer 10. SECS-II messages 40 are received and translated into a Script 46 by a SECS-II translation program 42. The SECS-II translation is driven by a Configuration 44 which defines the equipment specific implementation of its GEM interface. An example of a Configuration 44 for a Rudolph Focus Ellipsometer (FEiv) with GEM version 4.76 is found in the Attachment.

A Configuration 44 is comprised of Data Items (DI), Status Variables (SV), Data Variables (DV), Reports (RP), and Collection Events (CE). The Data Items (DI), Status Variables (SV), and Data Variables (DV) are defined in terms of their corresponding Information Format Codes (see Table T-2). One difference between these types is that Data Items (DI) are totally defined by their location in a list, while Status Variables (SV) and Data Variables (DV) are self defining. Note that lists are recursively defined as format zero (0) referencing other DI, SV, and DV elements.

Reports (RP) are numbered, and are defined as ordered sequences of DI, SV, and DV elements. The numbering and the corresponding reports can be either built-in to a specific GEM Interface Server 16, or can be dynamically defined by a user application. As implemented by SECS-II, reports are lists with two elements. The first element contains the report number, and the second element contains the report information, which can be either a list, or a data item. Note that there are two types of reports: equipment defined reports (RP) and dynamically defined reports defined in the Sample Plan 50.

The final cards in the Configuration File 44 are Collection Events (CE). These identify messages containing reports sent to and received from the GEM Interface Servers 16. Such a message will consist of a three element list. The first element in the list is an identifier. The second element in the list is the Collection Event Id (CEID). The third element in the list describes the event. Of interest here are those instances where the third element is a list containing one or more reports.

An example of such a message corresponding to the sample Configuration File 44 is included in the Attachment. Note that indention indicates list nesting level. The Attached example has an Event Id of 312. This corresponds to a WAFER.sub.-- COMPLETE Collection Event (CE). The third element is a list with two reports. The first report has a report number of 4, and the second report has a report number of 101. The first report is equipment defined in the attached configuration to consist of a single ASCII string (type 20) titled CE.sub.-- TIMESTAMP with a value of "950717150511".

The script 46 generated by the SECS-II translation program 42 is one of two primary inputs to a commercially available Tcl/Tk interpreter 48. The other primary input is a Data Collection Sample Plan File 50. An example of a Sampling Plan 50 follows the corresponding Configuration 44 in the Attachment.

A Sample Plan 50 consists of a series of procedures that are invoked at the occurrence of a corresponding specific event, which may be the encountering of a Collection Event (CE) in a message. Three of the procedures in the Attached example Sample Plan 50 will be discussed. The DCSP.sub.-- INIT procedure is invoked when the Sampling Plan 50 is initialized by the Tcl/Tk interpreter. It first disables the WAFER.sub.-- COMPLETE (CE#312). A dynamic report (RP#101) is defined to consist of seven (7) elements. The WAFER.sub.-- COMPLETE event is then linked to two reports: a staticly defined report (RP#4), and dynamically defined report (RP#101). The WAFER.sub.-- COMPLETE event is then reenabled.

The "edevent" and "defreport" commands result in messages being sent to the corresponding GEM Interface Server 16. The "edevent" command enables or disables event collection reporting for specific events. Disabled events are not reported by the GEM Interface Server 16, until reenabled. The "defreport" command generates a message that dynamically defines a report (i.e. RP#101).

The EVENT procedure is invoked every time an event message is received from a GEM Interface Server 16. In the example Sample Plan File 50, the EVENT procedure opens an event log, appends a single entry with the CE.sub.-- TIMESTAMP and event id (CEID) to the event log, and finally closes the event log.

The third procedure is a WAFER.sub.-- COMPLETE procedure. Its purpose is to process the information in the Server Generated Script 46. It operates by dynamically creating a statistics file using the sample's LOTID, WAFERID, and the CE.sub.-- TIMESTAMP of the sample. The procedure then inserts statistics into the dynamically created file, closes the file, and publishes the filename.

The fourth section of the Attached Example is a Server Generated Script 46. Each such Script 46 consists of "setting" a number of Tcl/Tk variables to specific values, conditionally invoking a general event (i.e. EVENT) procedure and a specific event (i.e. WAFER.sub.-- COMPLETE) procedure, followed by "unsetting" each of the previously "set" variables.

Values for the EQUIP.sub.-- ID, DATAID, and CEID variables come from the message header. In the Attached Example, setting the CEID to WAFER.sub.-- COMPLETE is based on the Collection Event (CE) 312 in the Attached Configuration File 44. The remainder of the variables "set" and "unset" in the Example Script 46 result from expanding the two reports into their constituent elements. All of the information for this expansion comes from the Configuration File 44 including the high level format of dynamically created reports (i.e. RP#101) and the received SECS event report message. Note in the Attached Example the use of the MEAS.sub.-- DATA list to contain replicated structures.

The fifth section of the Attached Example is the Resulting Output file 52 from the Tcl/Tk interpreter 48 interpreting the Example Server Generated Script 46 against the Example Data Collection Sample Plan 50. The Output File 52 is generated when the WAFER.sub.-- COMPLETE procedure is invoked by the Tcl/Tk interpreter 48. This Output File 52 includes the statistics from one set of measurements taken by one piece of Factory Equipment 18 and sent to the Host Computer 10 by the GEM Interface Server 16. Output Files 52 are often stored on Secondary Storage 30.

FIGS. 4-14 are flow charts that describe in more depth one implementation of the SECS-II Translation Program 42 used to translate SECS-II messages into a Script 46 using Configuration 44.

FIG. 4 is a flow chart that is entered when a collection event message is received, step 100, from a GEM Interface Server 16. First, the Element Format Code is extracted, step 102, from the message. If the Element Format Code does not identify a List (0), step 104, the routine error terminates, step 116. Otherwise, the list count is extracted, step 106, and validated, step 108. If not a valid list count, the routine error terminates, step 116. Next the DATAID is extracted and validated, step 110, the CEID is extracted and validated, step 112, and any corresponding reports are processed, step 114. If any of the above three steps fail, the routine error terminates, step 116. Otherwise, the routine returns normally, step 118.

FIG. 5 is a flow chart showing the operation of the get DATAID routine, step 110 in FIG. 4. This routine first extracts the Element Format Code, step 120, from the first element in the message. If the Element Format Code is a List Code (0), step 122, the routine error exits, step 124. Otherwise, the ASCII representation of the value is extracted, step 126, a line is sent to the Script 46 setting the DATAID to the ASCII string, step 128, and the routine returns normally, step 130.

FIG. 6 is a flow chart showing the operation of the get CEID routine, step 112 in FIG. 4. This routine first extracts the Item Format Code, step 140, from the second element in the message. If the Item Format Code is a List Code (0), step 142, the routine error exits, step 144. The ASCII representation of the value is extracted, step 146. This is the ASCII version of the Collection Event ID (CEID). A search is made for the Collection Event ID, step 148, in the list of Collection Events (CE) in the Configuration File 44. If a corresponding Collection Event (CE) is not found, step 150 the routine exits, step 154, indicating to the higher level routines to ignore this message. Otherwise, a line is sent to the Script 46 setting the CEID to the string corresponding to the Collection Event ID, step 156, and the routine returns normally, step 158.

FIG. 7 is a flow chart showing the operation of the Process Reports routine, step 114 in FIG. 4. This routine first extracts the Element Format Code, step 162, from the message. If the Element Format Code is not a List type code (0), step 164, the routine error exits, step 166. Otherwise, the List count is extracted, step 168, and used to initialize a loop. Each time through the loop, a check is made whether more reports are to be processed, step 170. If no more reports remain to be processed, step 170, the routine returns normally, step 172. Otherwise, a report is processed, step, 174. If the report was not processed successfully, step 176, the routine error returns, step 178. Otherwise, the routine iterates, checking for more reports, step 170.

FIG. 8 is a flow chart showing the operation of the Process a Report routine, step 174 in FIG. 7. This routine first extracts the Element Format Code, step 182, from the message. If the Element Format Code is not a List type code (0), step 184, the routine error exits, step 196. Otherwise, the List count is extracted, step 186. The List count is checked, step 188, and the Report ID is extracted and checked, step 190. If either test fails, the routine error exits, step 196. Otherwise, the Report Body is Processed, step 192. If the Report Body was not successfully processed, step 192, the program error exits, step 196. Otherwise, the routine returns normally, step 198.

FIG. 9 is a flow chart showing the operation of the get Report ID routine, step 190 in FIG. 8. This routine first extracts the Item Format Code, step 202, from the message. If the Item Format Code is a List code (0), step 204, the routine error exits, step 210. Otherwise, the ASCII representation of the value is extracted, step 206. A list of active reports is searched for the Report ID, step 208. It is important to find a definition of the active report since it contains the number and structure of the items contains in the report. If the Report ID is not found in the list, step 208, the routine error exits, step 210. Otherwise, the routine returns normally, step 212.

FIG. 10 is a flow chart showing the operation of the Process Report Body routine, step 192 in FIG. 8. This routine first extracts the Element Format Code, step 220, from the message. If the Element Format Code is not a List type code (0), step 222, the routine error exits, step 224. Otherwise, the List is Processed, step 226, and the routine returns normally, step 228.

FIG. 11 is a flow chart showing the operation of the Process List routine, step 226 in FIG. 10. This routine first extracts the List Count, step 232, to initialize a loop counter. The loop is entered, and a check is made for more List elements, step 234. If there are no more List elements to process, step 234, the routine exits normally, step 236 Otherwise, a check, step 238, is made against the number of expected items left to be processed for this List as defined by the Configuration File, 44. If the counts match then the next Format Code is extracted, step 240 else an Error Exit 239 occurs The remainder of the routine is best implemented as a case statement branching on element Format Code. If the Format Code indicates a List, step 242, the Process List routine is recursively entered, step 244. If the Format Code is not a List (0) then the ASCII representation of the value is extracted, step 246, and one line is then sent to the Script 46 for each value extracted setting the specified variable to the extracted value, step 248. The routine iterates, again checking for more List items, step 234.

FIG. 12 is a flow chart showing the Extract Item Value as ASCII String utility operation used in steps 126 in FIG. 5; step 146 in FIG. 6; step 206 in FIG. 9; and step 246 in FIG. 11. This routine first extracts the Format Code, step 252. If the Format code indicates an integer, step 260, the Process Integer routine is entered, step 262. If the Format Code indicates an ASCII string (20), step 254, the Process ASCII routine is entered, step 256. If the Format Code indicates a floating point number, step 264, the Floating Point routine is entered, step 266. This can be done is a like manner for Binary (10), Boolean (11), and JIS-8 (21) format codes. If the format code is recognized and successfully converted, the routine returns normally, step 258. Otherwise, if the format code is unrecognized, the routine error returns, step 268.

FIG. 14 is a flow chart showing the operation of the Process Integer routine, step 262 in FIG. 12. This routine first extracts the byte count, step 282. Next, the specified number of integers are extracted, step 284. The number of integers extracted is determined by dividing the element length in the previously extracted Item Format Code into the byte count extracted in step 282. Each integer is represented as a ASCII string and the strings are returned, step 286, and the routine returns normally, step 288. Note that the same routine is shown processing both signed and unsigned integers. It may prove expedient to separate the signed and unsigned integers into separate routines.

FIG. 13 is a flow chart showing the operation of the Process ASCII String routine, step 256 in FIG. 12. This routine first extracts the byte count, step 272. Next, the specified number of bytes are extracted as the ASCII string, step 274. The single ASCII string is returned when the routine returns normally, step 278.

FIG. 15 is a flow chart showing the operation of the Process Floating Point routine, step 266 in FIG. 12. This routine first extracts the byte count, step 292. Next, the specified number of floating point numbers are extracted, step 294. The number of numbers extracted is determined by dividing the element length in the previously extracted Item Format Code into the byte count extracted in step 292. Each floating point number is represented as an ASCII string and the strings are returned, step 296, and the routine returns normally, step 298.

Those skilled in the art will recognize that modifications and variations can be made without departing from the spirit of the invention. Therefore, it is intended that this invention encompass all such variations and modifications as fall within the scope of the appended claims. ##SPC1##