TWI397830B - Versatile semiconductor manufacturing controller with statistically repeatable response times - Google Patents

Description

General purpose semiconductor manufacturing controller with statistically repeatable response times [Priority claim]

This application claims to be a general-purpose semiconductor manufacturing controller with a statistically repeatable response time, which was invented by the inventor Lenoid Rozenboim and David Gosch on May 2, 2005. U.S. Provisional Patent Application No. 60/676,770. This provisional application is hereby incorporated by reference.

[Related application]

This application has been filed on August 22, 2001 by Uzi Lev-Ami and Yossef Ilan Reich, jointly owned by the inventor, for the purpose of monitoring the host-to-tool communication. U.S. Patent Application Serial No. 09/935,213, the disclosure of which is incorporated by the inventors Uzi Lev-Ami, Guenter Sifnatsch, and Mark Attwood. U.S. Patent Application Serial No. 10/819,903, filed on Apr. 7, 2004, entitled <RTI ID=0.0>> . Applications for co-applications are hereby incorporated by reference as if they were fully incorporated herein.

The present invention is directed to a general purpose semiconductor fabrication controller having a statistically repeatable response time.

The invention relates to a program I/O controller for semiconductor manufacturing, and the tool host can delegate the work of data collection, monitoring and control to the program I/O controller. In particular, the present invention relates to the ability to perform more than one data collection, monitoring, control, and response from a tool host with statistically repeatable performance and accuracy. The described embodiments use a prioritized, immediate operating system to control the collection of semiconductor manufacturing tools and materials from tools associated with the sensors. Vibrating is effectively reduced for the selected command and the statistically repeatable response performance of the sensor input during the selected fabrication steps.

Moore's law guarantees that computing power grows exponentially and has a cheaper price. The dynamic growth of processing power may make people think that semiconductor device manufacturing may be a profitable business, like oil exploration. The opposite is true. Semiconductor device manufacturing is a very cautious business because of the high value of manufacturing batches and the manufacturing process that is sensitive to small errors. The certification cycle for new equipment, as well as standards and modifications to legacy equipment, are lengthy and cumbersome. Even small changes must be thoroughly examined before mass production is released.

Key components used in semiconductor plants include tools (such as deposition chambers, reactors), sensors for monitoring tools (such as FTIR sensors, mass spectrographs, thermocouples), and storage and analysis of information from sensors related to tool operation. Host or distributed processor.

A prior application describes a transparent method of listening to data from a sensor to provide a host or distributed processor using high speed and error resistant techniques such as TCP/IP over Ethernet. This prior application was filed on August 22, 2001 by the inventors Uzi Lev-Ami and Yossef Ilan Reich as the method of monitoring host-to-tool communication. U.S. Patent Application Serial No. 09/935,213, the disclosure of which is incorporated herein by reference. This prior application describes the use of optically isolated connectors to eavesdrop on the listening communication from the serial communication of the tool or sensor. The use of eavesdropping proves that semiconductor plant communications and data collection architectures can be updated with low risk without the need for tools or sensor modifications. The possibility of updating can be demonstrated without the need to disassemble the existing communication architecture.

Next-generation semiconductor plant instrumentation and back-end analysis capabilities will involve adding smart controllers, such as program I/O controllers, to communicate between tools and sensors on one side of the program I/O controller, and On the other side, the tool host or distributed processor does not require replacement or sensing characteristics of the sensor. Increased processor power and reduced storage costs present opportunities for configurations that were previously unachievable in semiconductor plants. On April 7, 2004, the inventors Uzi Lev-Ami, Guenter Sifnatsch, and Mark Attwood applied for the application for the semiconductor factory. A smart controller having various capabilities is described in U.S. Patent Application Serial No. 10/819,903, which is incorporated herein by reference. The lack of the above-mentioned smart controllers cooperates with the tool host to perform multiple functions while providing statistically repeatable responsiveness. The jitter at the beginning or completion of the command is not well controlled in the current software structure.

By delegating data collection and critical control from the tool host or distributed processor to the program I/O controller, there is an opportunity to change the control model applied to the processing room. More preferably, it results in simpler configuration and control with statistically repeatable responsiveness and more flexible parts and systems.

The invention relates to a program I/O controller for semiconductor manufacturing, and the tool host can delegate the work of data collection, monitoring and control to the program I/O controller. In particular, the present invention relates to the ability to perform more than one data collection, monitoring, control, and response from a tool host with statistically repeatable performance and accuracy. The described embodiments use a prioritized, immediate operating system to control the collection of semiconductor manufacturing tools and materials from tools associated with the sensors. Vibrating is effectively reduced for the selected command and the statistically repeatable response performance of the sensor input during the selected fabrication steps. The specific aspects of the invention are described in the scope of the claims, the description and the drawings.

The following detailed description is made with reference to the drawings. The preferred embodiments are described to illustrate the invention without limiting the scope of the invention, which is defined by the scope of the claims. Those skilled in the art will appreciate various equivalent variations from the following description.

introduction

Historically, in semiconductor factories, host systems operate on mainframes, minicomputers, or workstations. The host system is typically monolithic, controlling and monitoring all or a large set of tools in a semiconductor plant. The host system relies on an adapter to interface with tools and sensors. The host system typically receives data from the tool and sensor and sends control commands to the tool. The host system often receives and generates a large amount of serial communication information.

The term tool host broadly includes a tool control host and a more restrictive or elastically distributed processor. The tool host includes both a host with integrated integrator tool control and a host with limited functionality and job-specific functionality running on distributed processors. The tool host contains products such as Consilium's FAB300 ^{T M} software, which is described as providing a single integrated plant management system driven by a centralized definition of customer-specific business processes. This type of tool host is designed to replace traditional manufacturing execution systems designed to control tools provided by different vendors. On the opposite side of the tool host family from the traditional manufacturing execution system, the part program can be run on a distributed processor to handle a variety of specific functions, not an integrated management system. Along the series, products such as Consilium's FAB300 ^{T M} software can be considered a tool control host for some purposes, and can be viewed as a program running on a distributed processor for other purposes.

Program I/O controller

The method disclosed herein uses a program I/O controller. The program I/O controller sends and receives signals that control a processing chamber or other semiconductor manufacturing processing device.

The program I/O controller communicates with the data user to collect information from the sensor. Data users can be traditional tool hosts that operate on large computers or newer software that can run on distributed processors. The data user can be a monolithic system or a joint package that operates independently or together. The program I/O controller can also monitor the data from the sensor, identify the event of interest and request more information from the collected data or change the sensor's collection plan in response to the monitored data.

Operating environment

Figure 1 depicts an environment in which the aspects of the invention are particularly useful. This describes the processing chamber 125, various inputs and outputs from the processing chamber plus sensors, control channels, and controllers. Chamber 125 can be used for various reactions such as deposition, cleaning, etching, implantation, ashing, and the like. Other types of tools, not shown, may also benefit from the aspects of the present invention.

The semiconductor plant network 111 potentially accessible via the Internet, virtual private network or wide area network 112 has controlled access via a controller, firewall or other connector 162 to the tool network 112. The tool network in this figure is shown as connecting the control and sensor that affects the processing chamber 125 to a ring. Those skilled in the art will appreciate that this architecture is merely illustrative; it is more likely to use serial communication, Ethernet or hierarchical communication than a ring in a semiconductor factory.

The gas input to the reaction chamber 125 contains gas passing through the gas box pressure transducer 113 and the mass flow controller (MFC) 114. Certain gases may pass through the ozone generator 133. Other gases or gas mixtures may pass through the reactive gas generator 115 and the gas composition monitor 117. The reactive gas generator 115 can generate plasma outside or within the processing chamber 125. The gas composition monitor 117 can be connected in series or in parallel with the reactive gas generator. The mass flow controller 114 can be in gas communication with the reactive gas generator 115 and the gas composition monitor 117 and ultimately or directly communicate with the process chamber 125 gas. Gas input devices 113, 114, 133, 115, and 117 are in communication with one or more bit controllers 142, chamber controller 152, and connection points 162. This communication typically includes both control and telemetry techniques. These devices may include both control of the operation of the response device or gas input and/or output, as well as sensors.

Other inputs may include material delivery 134, cooling subsystem 145, and various power injectors 153, 154, and 155. Reaction chamber 125 can be a deposition chamber, an etcher, a thermal processor, or other type of reactor. It can be a unit that is connected to multiple reactors for automatic disposal. Depending on the type of reaction chamber, material delivery system 134 can supply materials for deposition, such as on workpiece 136. The cooling subsystem 145 can help regulate the temperature within the chamber 125 since most of the chemical reactions are carried out at a temperature sensitive rate. The power source supplied to the chamber may be a microwatt power source 153, an RF power source 154 for generating plasma, and a DC power source 155 for generating plasma and heating the chamber or gas or other material supplied to the chamber. Other inputs, such as gas inputs, communicate with one or more of the bit controller 142, the chamber controller 152, and the connection point 162. This communication typically includes both control and telemetry techniques. These devices may include both control of the operation of the response device or control of both the inductive gas input and/or output and both of the sensors.

The sensor can respond to the condition of the chamber or actuate the effluent from the chamber. The sensor that responds to the condition of the chamber includes a wafer monitor 116 that is viewed through the window 126 into the chamber 125 for viewing the thickness, pattern, and other characteristics of the film (e.g., EPI-Online ^{T M} ), such as for etching process control. A processing monitor 127 and a pressure transducer 137 having an optical radiation monitor that interferes with the filter or interferometer. The sensor that operates the effluent from chamber 125 includes a leak detector 146, a vacuum gauge 157, and a discharge monitor 158. These sensors can interact with the pressure controller 148 and the control valve 147 and interact with the vacuum components and/or subsystem 156. They can also interact with the pump and/or the exhaust gas cleaner, which does not appear in the figure. These sensors communicate with one or more of the bit controller 142, the chamber controller 152, and the connection point 162. This communication typically includes both control and telemetry techniques. These devices that communicate with the sensors (e.g., 147, 148, and 156) can include both control and sensors.

The desired characteristic of a monitoring and control system is its determinism, that is, each command can be started or completed within a specified deadline. Both start and finish are taken into account, as some commands require a lot of time to complete, such as collecting five milliseconds of sampling in five minutes. Deterministic qualifications are considered to be the probability that an order will begin or complete within a specified response time. To test certainty, drill at least one million commands and organize their actual response times into a histogram. It is hoped that at least 99% of the order response time will fall within the required time limit. In addition, for a continuous operation of a few hours on a dedicated test starter (computer running the control section) through a dedicated network, it is desirable that the command be executed as much as possible within a specified (eg 5, 3 or 1 millisecond) time. The more "nine", but at least 99.99%, can also allow one of the 10,000 commands to have a delay that exceeds the specified response time or not execute at all.

Any communication technology has the inherent ability to deteriorate or otherwise fail to deliver digital information to its destination. This is due to some of the phenomena in both analog (electronic) and digital fields. Therefore, 100% certainty is an ideal that cannot be achieved, and actual implementation is evaluated based on how close they are to the ideal. These criteria can be expressed in terms of so-called "nine" or three sigma or five sigma efficiencies. Sigma refers to the standard deviation, which is a statistical measure.

Figure 2A-B depicts the performance and variation statistics as a distribution. The one-tailed distribution is depicted by curve 210. A performance criterion such as three (3σ) or five (5σ) sigma or α = .01 (two nines) or α = .0001 (four nines) is set, which is indicated by the cut line 211. The distribution of the response time conforms to the standard. For example, 99% of the actual response time falls to the left of the cut line 211. The two-tailed distribution is depicted by curve 220. A tolerance criterion such as three (3σ) or five (5σ) sigma or α = .01 (two nines) or α = .0001 (four nines) is set, which is determined by the cut line 222 on both wings of the target time 223, 224 shows. The distribution from the variation of the target time conforms to the standard if, for example, 99% of the difference between the actual and target time falls between the cut lines 222, 224. Although the distribution shown is a normal distribution, standard statistics or no parent number criteria can be applied to measure other distributions including skew distributions. These criteria are applied to a stimulus that is far enough apart to not overload the system. For example, a card rack embodiment of a program I/O controller has been measured to execute within 5 milliseconds for each I/O command, when such commands are received at intervals of at least 20 milliseconds. The limiting factor for this response time is the sequence of CANbus backplanes used in card rack mounts and other serial protocols used internally in supported I/O cards. It is foreseen that the customized integrated processing device will execute these commands in less than 3 milliseconds or 1 millisecond for each I/O command, without being limited by the frequency of the commands.

Based on experience, it has been determined that the use of a card rack mount reduces chattering and increases performance to a standard of 5 milliseconds. To meet a more precise tolerance, such as 3 milliseconds or 1 millisecond, a more integrated and customized hardware configuration as described below is required.

Controller application and architecture

Figure 3 is a block diagram of a communication coordinator coupled to a tool, sensor, and tool host or central host controller. This communication coordinator configuration includes two SEC/GEM interfaces 埠 312 and 316 and two network interfaces 埠 332 and 336. The controller contains logic and resources to communicate via the SECS protocol including the SECS multiplexer (MUX) 315. It further includes the logic and resources to implement the semiconductor factory side interface 334 to communicate with the data user and the tool side interface 335 to communicate with the tool, sensor, and instrument. The SECS MUX 315 and interfaces 334 and 335 are logically coupled to the data collection and publication resource 325. On the semiconductor plant side of the communication coordinator, the conventional tool host 311 can be connected via an SECS compliant communication channel 312, which can be a later version or subsequent to SECS-I, HSMS or SECS. In an environment where non-semiconductor plants to which the present invention can be applied, other protocols can be used to interface with monitored tools such as medical tools or digitally controlled machine tools. It can also be connected by a semiconductor factory side agreement different from SECS, carried by network 322 to storage 331 and reporting 321 resources. On the tool and sensor side of the communication coordinator, an SEC/GEM tool interface 317 to the tool or tool group can be connected. Although the controller is shown in the figure to be connected to the sensor via a network, it may alternatively use SECS-I or another sequence-based protocol to connect to the sensor. Introducing FIG. 3, the program I/O controller can be directed to handle both the tool interface 316 and the instrument interface 336. The program I/O controller can replace the communication coordinator.

Figure 4 is a block diagram of a communication coordinator that uses a single type of communication channel to communicate with tools, sensors, and tool hosts. Figure 5 depicts the use of various communication channels. In Figure 4, the status of the SECS is described. The communication coordinator 403 uses the SECS protocols 407 and 409 to communicate with the tool 401 and the sensor 402. The bond 408 between the tool 402 and the sensor 402 relates to any form of energy or force that can be sensed normally, including any perception discerned in the discussion of FIG. In Figure 5, a more complex combination of SECS and network communication is described. The only SECS communication channel 407 in this case is between the communication coordinator 403 and the host 401. The tool side network 509 connects the communication coordinator with the sensors 402A-B, the managed switch 513, and the network attached storage (NAS) 515. The semiconductor factory side network 519 integrates the communication coordinator with an analysis software 523 such as a conventional tool host or distributed processor, an extension network 525 such as an internet, VPN or private internal network, and stores or stores the communication coordinator. A database of published materials 527. Alternatively, the database can be located on the communication coordinator 403. The actual implementation of the alternative will be discussed in the next section. In Figure 4, a program I/O controller can be introduced between the communication coordinator 403 and the tools and sensors 407 and 409 to allow the communication coordinator to process the SECS protocol information. In FIG. 5, a program I/O controller can be introduced between the communication coordinator 403 and the tools and sensors 401 and 402. Alternatively, instead of the SECS protocol, managed switch 513 and NAS 515, the program I/O controller can replace the communication coordinator 403.

Card case embodiment

The implementation of the first program I/O controller is based on the 3U "Euro card" type used in the previous product. It reuses existing discrete and analog I/O cards that have been modified to use simplified high-performance protocols on CANbus. Add an additional 3U card that implements two Ethernet ports (interconnected with Layer 2 switches) and supports program I/O controller software components. In one embodiment, it uses a proprietary protocol on CANbus to access the actual I/O points. This implementation is modular and supports up to 16 I/O cards in a single card rack. The system automatically detects which I/O card has been inserted in each available card slot and configures all software components (control and data collection) to reflect the automatically detected configuration.

Figure 6 is a block diagram of the height of the actual architecture of the program I/O controller. In this embodiment, the SCAN bus 621 connects the card in the card bay to the interface controller 631. The interface controller can be a Netcom card with a Motorola Coldfire 32-bit processor, network connectivity (front-end 642 and back-end 643), one or more UARTs with RS232 and RS485 support, and hot-swap I/ O for the internal CAN bus controller. The Ethernet connector prioritizes control and other functions. The card may include an interlock card 611, such as the MKS instrument CDN497-C-E configured for two slots and having 36-68 relays and 8-32 DIDO channels. An effective chain can be represented by a status light on the chain card. They can include digital I/O 612 and analog I/O 613 cards, such as the MKS instrument CDN497-C-E with 48 in/out 埠 with low active signal operating at 24v and an inverter coupled to 12-bit. MKS instrument 496-C-E with 32 analog inputs and 16 analog outputs.

This modular design is best suited for small applications. It saves development costs by reusing existing I/O cards and requires only the development of custom bases and distribution boards for individual application needs. Modular design is more expensive than a fully customized single stone implementation based on the price per unit. However, it does not achieve the desired fast response time and narrow tolerance.

Customized single stone embodiment

When a remote I/O unit is provided in a large number of customized versions, the price can be more competitive. Eliminating modularization can significantly reduce the cost of hardware parts. From the embodiment of the card rack, learning that the sequence backplane (based on CANbus) has a negative impact on performance. In view of this, in order to improve performance, all I/O signals can be connected to the processor through a parallel backplane and a data bus.

Single firmware multiple hardware

The elimination of hardware modularization (cards, slots, connectors) does not require logical exclusion. By making all I/O clusters look like "logic cards", the main controller firmware can discover the type and number of I/O signals present in the hardware and perform all software object mappings based on this configuration. This produces a software that can operate a single version of a different hardware embodiment. There are new features and debugging mechanisms on many other logically similar but actually different units that reduce costs.

Figure 7 is a block diagram of the I/O and COM architecture with MODBUS/TCP interface. The instant control 711 is coupled to the I/O driver 731 (i.e., via the SCAN bus), to the MODBUS TCP driver 733, the data logger 712, and the diagnostics 713. I/O driver 731 can be coupled to I/O channel 741, such as a CAN I/O channel. The higher priority of deterministic operations can be delegated to the work shown in this figure, using an instant embedded operating system based on a preemptive priority based ordering, leaving a lower priority for other work and The use of the remaining resources gives time-consuming but non-critical processing. Jobs 713, 724, and 734 are lower priority jobs with heavy processing requirements. The data logger is coupled to data collection 723 and user interface 724. Both the data collection and user interface can be accessed over TCP/IP 743 and Ethernet 753 via HTTP server 734. Data logger 712 is also coupled to MODBUS TCP 733 resources, which can carry information via gateway 732 and UART 742 or via TCP/IP 743 and Ethernet 753.

Common characteristics

Both hardware embodiments can provide access to I/O signals using existing standard MODBUS/TCP. Instead, it can be used for the exclusive implementation of MODBUS on a more streamlined UDP protocol, which requires a slightly faster response time. The choice of MODBUS allows the program I/O controller to be quickly and inexpensively integrated into new and existing semiconductor manufacturing process control equipment because the MODBUS specification is open and freely available. There are several MODBUS implementations that can be used as reference codes for controlling software integration.

FIG. 8 is a height block diagram of the association of program I/O controllers 820 and 830 to tool host 810. The tool host 810 includes a control program 811, a MODBUS/TCP main application interface 812, and a web browser 813. The program I/O controller 820 includes a MODBUS/TCP interface 821 and a network server 822. The MODBUS/TCP interface controls the loading and execution of the Javascript regular 823 and provides direct access to the I/O interface pin 825. Network server 822 provides access to data collection 824. The additional program I/O controller 830 has the same capabilities as 820. The tool host can be connected to the program I/O controller via the communication of the Ethernet 815 or the program I/O controllers 820 and 830 can be interconnected.

The Program I/O Controller embodiment uses an efficient and deterministic embedded instant software platform to effectively exceed the performance and certainty of traditional industrial networks including DeviceNet, thereby reducing the risk involved in migrating control systems. The following are some of the features provided by these program I/O controller implementations for MODBUS remote I/O control.

At the lowest level, some specialized application relay circuits or interlocks are designed to prevent the processing machine from entering a potentially dangerous state. This method has traditionally been used as part of any semiconductor processing control application and is one of the main factors that require custom-built control of a particular I/O subsystem design. These linkages may prevent any other unexpected event of a logical software error or a combination of potential hazards that may trigger a gas and/or energy level. Some program I/O controller embodiments are custom or semi-customized relays or interlock circuits, as well as additional electronics that allow monitoring of these relays via a network connection.

At the second level, the controller I/O device can internally prevent the failure of its embedded software. The I/O signals can be controlled by a programmable logic array (such as a CPLD) that can turn off all discrete outputs if the program I/O controller firmware is unable to provide a "heartbeat" pulsed I/O circuit at predetermined intervals. Similarly, the analog output will be reset to a zero volt level if the firmware appears to fail. The state of these outputs, the off state of the discrete outputs, and the analogy of 0 volts, have traditionally been designated as safe output states in semiconductor processing equipment control systems.

At the highest level, the firmware feature maintains the output current and maintains the heartbeat pulse as long as the program I/O controller continues to send MODBUS commands at a predetermined frequency. If the host computer running the control logic fails, the program I/O controller firmware will immediately transition all outputs to a safe state until the tool host resumes operation. This feature in the program I/O controller product can be eliminated by switching the operating mode to diagnostics. Whenever a diagnostic or any higher level debug mode of operation is selected, the program I/O controller unit can be clearly indicated by displaying a yellow or amber status light on its front panel (instead of the normal green indication). Indicates this mode.

Diagnostic tools

These program I/O controllers present the network interface of the remote I/O unit. A personal computer with an Internet browser can be used to directly access the I/O unit user interface for various needs. This user network interface is additional to the normal MODBUS control services provided by the program I/O controller and can be used during the development, manufacture, and maintenance of the processing device. During development, the embedded web user interface allows engineers to build and test their processing equipment without having to wait until the software for the application is fully developed and tested.

The network interface avoids processing control software that needs to be exposed to lower-level diagnostic interfaces and allows technicians to monitor inputs and use outputs at the lowest level. The network diagnostic interface can be used to meet the needs of manufacturing testing. For maintenance debugging - no special software or hardware tools are required; PCs can be used to connect to I/O units via Ethernet. Moreover, the training needs for field personnel can be greatly reduced, because the diagnostic network interface is very intuitive and can be used with almost no special training. But the diagnosis sometimes conflicts with security requirements. Therefore, when the I/O unit is in production mode, the diagnostic network interface is reduced to the monitor-only mode.

When in production mode, the program I/O controller firmware enables a security watchdog that keeps the output valid as long as the tool master is active but will maintain only the tool master or master or central controller output The state is controlled exclusively and will also be indicated by a flashing green status indicator on the front panel. However, when switching the program I/O controller firmware (such as by a rotary switch) to the diagnostic mode, the security monitor will be invalid, thereby removing the need of the tool host and allowing the network user to face the output. Control and indicate this state with a flashing amber status light.

Dual features - remote I/O and data collection

Part of the program I/O controller product architecture supports the MKS instrument TOOLweb ^{T M} architecture for data collection and analysis of process error detection and advanced process control. Later versions of TOOLweb use high quality materials collected from as many processing variables as possible. The implementation of the data collection agent's program I/O controller, combined with TOOLweb's ToolSide protocol, allows almost all of its I/O signals to be collected at high frequencies. Therefore, the program I/O controller containing the described features creates an opportunity for detailed analysis of TOOLweb data collection and basic processing.

Experience has confirmed that the current implementation of process control software data collection often lacks the quality and total processing power required for complex mathematical model methods. The current control soft system is mainly used for control processing, so any item that is not controlled tends to be in a lower position in the implementer's priority order, so if implemented, it is usually not enough.

sampling

Sensors that monitor semiconductor processes are used to control the program and maintain certain critical processing parameters within the assigned tolerances. In addition, after wafer completion, data is increasingly collected, stored, and analyzed for use as a defect analysis. The readings from the sensors connected to the processing chamber are collected and stored for off-line analysis, which is intended to correlate various data resources to discover the source of processing failures or to predict the preventive maintenance required on the processing equipment. Sensors typically include various gas pressure sensors, temperature transducers, mass flow controllers, RF and DC power and energy transfer devices, and more.

The information collected should be of a quality that can be used for subsequent mathematical or statistical analysis. The measuring device shall produce the correct number of digital reads of the underlying physical quantity. The measurement samples should be taken at intervals that are much smaller than any expected rate of change for any throughput, so any rate of change or rate of change or any anomaly in the pattern can be readily described by any analytical method used. Sampling should be taken at specified and statistically repeatable intervals.

When the instrument obtains the current record of each measurement, the value of the sampling time or at least the sampled number can be derived therefrom. This time stamp for collecting data can be as important as its value, especially if there is chattering during the sampling time. The fuze recorded or derived should be at least as good as the measured value, otherwise it will not be used to calculate the derivative of the variable. The derivative of the physical measurement reflects the rate of change or the "slope" of a given measurement and can play an important role in detecting various processing anomalies or effectively predicting the need for preventive measurements. For example, during the chamber heating phase, a gradual decrease in the temperature derivative (where the temperature gradient is positive) represents a gradual fatigue of the heating source, and a significant steep drop in this amount is a positive sign that the heating source used has been ineffective. When cooled, where the temperature derivative is negative, a decrease relative to the previous amount implies that the cooling may be too rapid, which increases the crystal structure pressure in the material being processed (ie, the wafer).

Control of separation from data acquisition

In sensor and material transfer controllers developed with advanced data collection considerations, resource usage is strictly prioritized to prioritize control over data collection without adversely affecting the quality of the data collected. This involves a prioritized, immediate operating system that is responsible for ensuring a statistically repeatable response to control commands and measurement queries while allowing the data collection work and reporting to use the remaining resources.

The use of different agreements for control and data collection has its benefits because of the need for both activities. Control focuses on deterministic response time and effectiveness, while data collection prefers low complexity and ease of integration with IT systems and databases. The use of different protocols also distinguishes between software components that extend these two activities. In some cases, it is appropriate to use an individual hardware interface for each of these activities, for example, using DeviceNet or an analog interface for control, and using IT-friendly Ethernet and TCP/IP for data collection. With HTTP network technology. In other cases, MODBUS/TCP for operational control on the same Ethernet network for HTTP/XML data collection protocols is also appropriate.

Collection time decoupling and batch transfer

One method of data collection is to have sensors equipped to ensure accurate timing of data collection. The “data collection plan” is the introduction of the body of the sensor. The data collection client thus needs to define a collection plan that will trigger the lightweight data collection resident program to begin sampling data at precise intervals, adding timestamps to data samples, and storing the data in a circular buffer of predetermined size.

Thereafter, the data collection client will generate a periodic request for resource priority to retrieve buffered samples for a particular collection plan and typically receive all samples from the previous data transmission record. The interval between data retrieval requests need not be accurate or deterministic as long as the request is made at intervals that avoid ring buffer overload. Due to the time stamp attached to the data, the latency of any information will not affect the information collected. If the buffer is large enough to hold a few seconds of sampling, there is almost no data loss unless there is a devastating failure of the data collection client or the underlying network architecture. In the definition of the collection plan, the data collection client defines which measurements will be collected and how often. Sensors with sufficient resources can accommodate multiple data clients and collection plans.

Data sampling can be arbitrarily added to the sequence number. The data collection client uses the sequence number to avoid recording duplicate data samples and detecting missing data samples. The sequence number 1 supports the stateless implementation of the data collection server, allowing the data collection server to track the sequence number of the last captured data sample and request the following sequence number as the starting data. It is known that stateless servers implement efficient use of both memory and CPU resources, reducing the resource requirements for sensor storage data.

The sampling of the data of the sensor buffer can be processed substantially in batches, so that the client data request services multiple data samples, up to the maximum number of buffers. This will expand the data associated with multiple data sampling requests, so that the data collection process can more effectively use the bandwidth and reduce the average payload generated.

Sensor protocol implementation

Several sensors and material transfer products are implemented in various development stages to perform sampling buffering. They use the data model of the application XML, which is passed on the implementation of the HTTP stateless client-server. The sensor implements a server. The embedded HTTP server directly provides the user interface to the instrument for configuration and diagnostics. The XML command and response command form allows the data collection client to automatically discover these sensors on the network, retrieve complete forms of measurements (ie, variables) for collection, define specialized application collection plans, and capture buffered Data sampling.

Some of these sensors use different interfaces for control, in some cases using individual actual DeviceNet links, while others share the same Ethernet network with MODBUS/TCP. It has been confirmed that HTTP data collection and user interaction does not result in statistically repeatable performance or timing failures.

Priority ordering

In order to implement the two features of the program I/O controller - hard real-time traffic-oriented network I / O control and the publication of the time elasticity of the collected data - these sensors are characterized by an advanced real-time software foundation. Based on this foundation, both applications are established in a manner that strictly controls the use of resources and prioritizes the allocation of resources, so that the data collection activities within the allowed performance parameters do not reduce the control command performance of MODBUS. . Moreover, the publication of the collected data enables sufficient residual bandwidth to be used to publish the collected data without loss of quality or quantity under the expected MODBUS activity.

In addition to prioritization, the total number of variable samples and the frequency of collection are limited, so that when data collection activities are combined with MODBUS, the available resources are not overused, resulting in the loss of collected data or unpredictable system behavior.

Logical entity data

For control purposes, the program I/O controller allows access to the lower level of its I/O by the number of connector pins, and the value is represented by a simple binary form. It is expected that the tool host will perform the mapping of the number of connector pins to the variables themselves, and CONTROLweb will not perform any translations to preserve the original values and maximize performance.

On the other hand, for analysis, the data element should have a logical meaning - the variable name should represent the actual parameter, and the size of the analog value can be scaled and offset to the measured physical unit. The compensation values should be calibrated for the sensor so that the values collected by the sensor from similar processing chambers can be compared.

To increase the symbolic representation of the connector pins, these program I/O controllers implement a variable mapping table that is configurable and stored in non-volatile memory, with assigned logical names and numbers adjusted to the I/I of interest. O signal. Note that for some program I/O controllers, the number of I/O pins exceeds the number of symbol variables in the map. If only the mapped I/O pins are accessible, the mapping table also identifies the I/O signals of interest for data collection and analysis.

The program I/O controller is configured for sensors and controls attached to the I/O pins. Identify and name the variables of interest, and if necessary, apply a scaled offset of the numbers to make the reported values more meaningful, preferably in standard units of measurement. Since the data collected by symbolic naming still recognizes its meaning even when the material is taken offline or off-site, only a small amount of detail can be obtained for a given tool. The collected values can retain their meaning for a long time, even if the actual tools are upgraded or updated at the time.

When configuring a program I/O controller installed on a similar tool, you can simplify the configuration by downloading the configuration to a text file and uploading the text file to other program I/O controllers. These configuration files can be edited offline using standard PC software tools so that the configuration can be prepared by the processing expert in the off-going state.

Remote I/O intelligence, scripting

The initial goal of the card rack controller architecture is to insert the fastest possible response time on MODBUS on the Ethernet and improve the repeatability of the control beyond the slower commercial bus such as DeviceNet. degree. It has been learned in many cases that the bottleneck of the timing of processing accuracy lies in the tool host or the main controller itself and the operating system used to implant the tool host. Some existing main controllers operate within a tolerance of 50 milliseconds, others are within a tolerance of 100 milliseconds.

In fact, these control systems are complex and often developed over time by a large design team. The development tools used can only be obtained on a general purpose computing platform. The complexity of these old softwares is the main cause of their inaccuracy.

To improve the accuracy of the processing without giving each processing tool a dedicated workstation, these program I/O controllers implement a limited but powerful programming environment to control remote I/O. These programming environments are not intended to replace traditional processing control software systems, but rather assist them by delegating processing control logic to those parts with critical timing requirements to instant-based program I/O control units, instant-based programs I /O, the control unit is maintained under the control of the tool host or the main controller.

The software or operator identifies small but critical processing steps and translates the required monitoring and feedback into small programs that can be executed within a resource-constrained and deterministic operating environment with timing accuracy, such as better than 5 The accuracy of milliseconds, better than 3 milliseconds or better than 1 millisecond.

Language, programming tool

Program I/O Controller Area Programming supports a subset of the ECMA standard Javascript language, which is an object-oriented event-driven interpreted programming language. Download a program to the I/O unit in full text, and then use the specially assigned program status register to evoke the program, which can be set and monitored by MODBUS. This program status register is also used by the tool host to monitor the execution and completion of the program. One processor family suitable for implementing this environment is the Motorola ColdFire family of Reduced Instruction Set Computing (RISC) microprocessors. The designated MCF5282 of the microprocessor in this family. Because these processors are derived from the respectable 68000 processor family, there are many development tools and various real-time operating systems. Block diagrams and details of this processor family are available at www.freescale.com.

A limited number of scripts should be executed at any given time, and these programs should be limited in size. Introducing size limitations and removing certain language tools or features from this implementation to reduce the risk that user-written scripts will exceed available computing resources and result in undefined behavior of the control subsystem. Although it is still possible to programmatically assign a program I/O controller to a portion of the lower order priority than the instruction code compiler via programming errors. Hazardous features include a network user interface, data collection, and adjacent script compilers that run other parallel scripts. It is recommended to keep these user scripts short and simple, avoiding tight loops and using event notification where possible.

A special web page will display the most recent script execution history. This page provides more details than the program status register available on MODBUS.

A class system is established within the instruction code compiler to represent the regional I/O signals on the program I/O controller so that the instruction code can exercise control over the output and monitor the input. Also, discrete inputs can generate events that can be assigned to particular instruction code functions and that are asynchronously evoked when these inputs change values or states.

Virtual I/O, script control and monitoring

The instruction code compiler is assigned a special 16-bit scratchpad that can be read and written via MODBUS to control and monitor the state of the corresponding instruction code compiler. The master or central controller can write to the scratchpad to start or terminate the execution of an instruction code, or read the scratchpad to monitor the state of the compiler, that is, if the instruction code is operating, or has ended normally, Or the abnormal end, in the latter case, the register will contain the instruction code exit code.

The program control registers described above can be further generalized, and a limited number of additional registers can be predefined for each instruction code compiler. These additional registers, like the program status register, can be accessed by MODBUS for read and write access and can be accessed by instruction code running on the appropriate compiler. These registers can be used for various purposes involving communication between the script running on CONTROLweb and the host controller.

Remote I/O, decentralized instruction code

In addition to complete unobstructed access to regional I/O signals, the script compiler adds a class system that can be set to represent I/O signals that are connected to other program I/O controller entities, but After association, it behaves almost like a regional I/O signal, with the same basic access methods and attributes. I/O signals (remote I/O operations) located on other program I/O controllers are usually slower to respond and cannot be used as a source of asynchronous events.

This remote I/O on other program I/O controllers is implemented by adding a MODBUS client (primary) implementation to the instruction code compiler, which provides additional program I/O control to the same network. Access to I/O signals on the device.

Taking into account the above restrictions, this convenient device should be used with caution. One of the best uses is to synchronize parallel scripts on different program I/O controllers, which combine to perform a single processing sequence where the number of I/Os and/or processing entities are laid out for all relevant I/O. It is not possible to connect signals to the same program I/O controller.

Handling recipe assignments

A manufacturing process detail is often referred to as a "recipe," which is in fact a program that dominates the sequence, time, and threshold details of the chemical or segmentation process. In some previous processors, the factory control host downloaded the recipe to the room to process the control computer (or select a previously stored recipe). This recipe is then executed by the host controller for each of a single wafer in a batch. The primary controller's goal is to repeat this recipe only for each wafer in a given batch, or any other batch, so that the results of each process (such as the thickness of the deposited layer) are the same. However, as previously stated, current processing control systems based on computing platforms having the general purpose of large and complex software systems have discretionary limitations in timing accuracy, and respond quickly to input changes and react quickly enough. Limited ability. These limits ultimately inhibit the repeatability of the formulation and are a significant constraint on the current processing yield and yield factors. Therefore, some processing speeds are deliberately slowed down to stop them in time.

The solution to this problem with these improved program I/O controllers is to effectively delegate recipes that are considered critical to instant I/O devices based on instant.

The main processing controller, instead of iteratively processing one recipe instruction at a time (for current standard jobs), will first organize a recipe and define those parts that require timing and response accuracy that are beyond the capabilities of the main controller. These key recipe steps are compiled into scripts and loaded into the appropriate program I/O controller for subsequent execution. Next, the program I/O controller will iteratively execute the recipe: execute those parts that are not marked as "critical" by their own resources, and when they reach the "critical step", start the instruction code to execute the remote I/ One of the O units, and the execution of the instruction code is monitored via one or more virtual I/O variables that are used by the instruction code to indicate its status.

During compilation, the host controller replaces all references to logic values and states to physical or mapped I/O signal references, otherwise the recipe steps are converted to instruction code programs. One way to achieve this is to use a script template in which pre-existing instruction codes are written to a particular recipe step type, and the main controller will then need to place the actual I/O reference and the specific time and threshold to The predetermined command code location.

Some specific embodiments

The invention can be practiced or adapted to implement the apparatus. The same approach can be seen from the tool host, servant or program I/O controller, and the mode of operation agreement or system. The invention can be an article of manufacture, such as recording a logical medium to perform the method.

One embodiment is a method of controlling the timing of semiconductor fabrication processes. This method uses a tool host and a program I/O controller. The program I/O controller includes an electrical interface for processing and monitoring of the processing room, and supports accurate timing input and output through the electrical interface. The tool host contains a symbolic representation of the programming environment of the electrical interface. The method includes, at a tool host, preparing a control program including instructions for causing the program I/O controller to sample input and control output via the electrical interface. The control program is loaded from the tool host to the program I/O controller. At the program I/O controller, upon receiving a command to evoke the control program, the control program is operated to generate a sample input and a statistically accurate timing of the control output via the electrical interface. The sample input and the control output are considered to be statistically accurate when the variation in the range of 99.99 percent of the variation distribution between the target time and the actual time is less than or equal to five milliseconds. In some examples, the target time may be as fast as possible and the execution of a command may be less than or equal to five milliseconds. In other examples, the target time can be when the input reaches a certain level.

One aspect of this approach is to prepare the control program in an interpreted programming language such as Javascript. Using an interpreted program language to facilitate loading of control programs does not disturb the order of execution of commands or other programs. In another aspect, it can be combined with the first to load the control program to load processing priority, which retains the priority of the processing command of the program I/O controller, regardless of other program I/O controllers. Or the tool host received it. Yet another aspect involves loading the control program without taking the program I/O controller offline from at least some of the sample inputs and control outputs through the electrical interface.

In at least one embodiment, the input of the sample and the output of the control are performed in a range of 99.99 percent of the distribution of variations between the target time and the actual time of less than or equal to 3 (three) milliseconds. The single stone controller embodiment can provide accurate timing of the sampling input and control output such that the range of 99.99 percent of the distribution of variation between the target time and the actual time is less than or equal to one millisecond.

In operation, the method includes the program I/O controller setting the virtual digital signal of the corresponding input and the changed output of the tool host through the electrical interface. The program I/O controller sends these virtual digital signals without disturbing the statistical accuracy of the sampling and control time. The virtual digit signal can include a timestamp. The tool host, in response to the virtual digit signal, can send a command to the program I/O controller to cause the program I/O controller to stop operating the control program.

The program I/O controller can, in response to the control program, send control commands to another program I/O controller at a statistically accurate time. The tool master can be configured to accept the timing tolerances of the control steps in a recipe and determine whether to delegate those control steps to the program I/O controller. When judging the time to delegate the control step, a control program can be prepared and loaded into the program I/O controller.

Another embodiment is a method of controlling a program operating in a processing chamber at repeated intervals using a program I/O controller in conjunction with a central controller. The method includes, in monitoring and controlling one or more aspects of an operating chamber of the program, the program I/O controller receives a control command from the central controller and receives a first statistic of five milliseconds or less after receiving The control command is processed in a repeatable short interval. When the time in the range of 99.99 percent of the time distribution is less than or equal to the short interval, the short interval is considered to be statistically repeatable. The program I/O controller, also sampling one or more sensors coupled to the processing chamber and statistically repeatable in the sampling schedule, without statistically repeatable in the processing of the control command This sampling is provided within the tolerances. The tolerance is considered to be statistically repeatable when the variation in the range of 99.99 percent of the distribution of variation between the target time and the actual time is less than or equal to the tolerance. Depending on the hardware embodiment, the first statistically repeatable short interval may be 3 ms or less or 1 ms or less. Also depending on the hardware embodiment, the statistically repeatable tolerance can be five milliseconds, three milliseconds, or one millisecond or less.

Implementing the above method, buffer sampling may include buffering the timestamp of the corresponding sample. The program I/O controller may distribute at least some of the buffered samples without losing statistical reproducibility of the processing of the control commands or losing statistical reproducibility of the samples. Instead, the method further includes dynamically loading the load from the memory of the program I/O controller without losing the repeatability of the processing of the control command or losing the statistical reproducibility of the sample Instructions. The instructions may include a result of the selection that should be sampled, the response occurring within a second statistically repeatable short interval that is less than reporting the sample to the central controller and receiving the response. The statistically repeatable feedback interval required for the command. Alternatively, the second statistically repeatable short interval may be less than one-and-a-half the length of the first statistically repeatable short interval.

The method further includes receiving, identifying, and dynamically loading the instructions into the memory of the program I/O controller without taking the program I/O controller offline from the monitoring and control aspects of the operating processing chamber. Alternatively or in combination, the method for the method may include the program I/O controller distributing at least some of the buffered samples without losing statistical reproducibility of the receipt and processing of the control commands or loss of dynamics in the load instruction Statistical reproducibility of implementation.

Another aspect of the method may be that the statistical repeatability of the reception and processing of the control command is lost or the statistical reproducibility of the dynamic execution lost in the load instruction, the program I/O controller is The memory dynamically executes the load instruction. In particular, the instructions may initiate a closed loop control comprising at least one aspect of the operational processing chamber, the initiation being second statistically less than a feedback interval or less than one of the first statistically repeatable short interval Repeated within a short interval. In some examples, the second short interval may be less than one fifth of the first statistically repeatable short interval. The method can include the program I/O controller receiving, identifying, and dynamically loading instructions into the memory of the program I/O controller without taking the program I/O controller from the monitoring and control mode of the operating processing room offline. . The program I/O controller distributes at least some of the buffered samples without losing statistical reproducibility.

As a device, the program I/O controller can include a device that is adapted to communicate with a central processing unit, memory, and logic and resources coupled to the device, and the memory is adapted to perform the method and any aspect of the method described above.

The present invention has been described with reference to the preferred embodiments and examples, which are intended to be illustrative and not restrictive.

111. . . Semiconductor manufacturing network

112. . . network

113. . . Gas box pressure transducer

114. . . Mass flow controller (MFC)

115. . . Reactive gas generator

116. . . Wafer monitor

117. . . Gas composition monitor

125. . . Processing room

126. . . window

127. . . Processing monitor

133. . . Ozone generator

134. . . Material delivery system

136. . . Work piece

137. . . Pressure transducer

142. . . Digital controller

145. . . Cooling subsystem

146. . . Leak detector

147. . . Control valve

148. . . pressure controller

152. . . Room controller

153. . . Microwatt power supply

154. . . RF power supply

155. . . DC power supply

156. . . Subsystem

157. . . Vacuum gauge

158. . . Discharge monitor

162. . . Junction

210. . . curve

211,222,224. . . Chop line

220. . . curve

223. . . Target time

311. . . Tool host

312, 316. . . SEC/GEM interface埠

315. . . SECS multiplexer

317. . . SEC/GEM tool interface

321. . . report

322. . . network

325. . . Data collection and publication resources

327. . . sensor

331. . . Storage

332, 336. . . Network interface埠

334. . . Semiconductor factory side interface

335. . . Tool side interface

337. . . instrument

401. . . tool

402. . . sensor

402. . . A-B sensor

403. . . Communication coordinator

407, 409. . . SECS Agreement

408. . . link

509. . . Tool side network

513. . . Managed switch

515. . . Network Attached Storage (NAS)

519. . . Semiconductor factory side network

523. . . Analysis software

525. . . Extended network

527. . . database

611. . . Chain card

612. . . Digital I/O

613. . . Analog I/O

621. . . SCAN bus

631. . . Interface controller

642. . . front end

643. . . rear end

711. . . Instant control

712. . . Data logger

713. . . Diagnostic

723. . . data collection

724. . . user interface

731. . . I/O driver

732. . . Gateway

733. . . MODBUS TCP driver

734. . . HTTP server

741. . . I/O channel

742. . . UART

743. . . TCP/IP

753. . . Ethernet

810. . . Tool host

811. . . Control program

812. . . MODBUS/TCP main application interface

813. . . Web browser

815. . . Ethernet

820, 830. . . Program I/O controller

821. . . MODBUS/TCP interface

822. . . Web server

823. . . Javascript convention

824. . . data collection

825. . . I/O interface pin

Figure 1 depicts an environment in which the aspects of the invention are particularly useful.

Figure 2A-2B depicts the performance and variation statistics in a distribution map.

Figure 3 is a block diagram of a program I/O controller that communicates with tools, sensors, and tool hosts using a single communication channel. Figure 4 depicts the use of various communication channels.

Figure 5 is a block diagram of the software and hardware components that can be used to build a program I/O controller.

Figure 6 is a block diagram of the height of the actual architecture of the program I/O controller.

Figure 7 is a block diagram of the I/O and COM architecture with MODBUS interface.

Figure 8 is a block diagram showing the height of the program I/O controller associated with the tool host.

711. . . Instant control

712. . . Data logger

713. . . Diagnostic

723. . . data collection

724. . . user interface

731. . . I/O driver

732. . . Gateway

733. . . MODBUS TCP driver

734. . . HTTP server

741. . . I/O channel

742. . . UART

743. . . TCP/IP

753. . . Ethernet

Claims (31)

A method of performing precise timing control of a semiconductor manufacturing program using a tool host and a program I/O controller, wherein the program I/O controller includes an electrical interface for processing room monitoring and control and supports accuracy via the electrical interface Timing input and output, and the tool host includes a programming environment symbolically representing the electrical interface, the method comprising: at the tool host, preparing to include the program I/O controller to sample input and control via the electrical interface a control program for outputting an instruction; loading the control program from the tool host to the program I/O controller; and operating the control when the program I/O controller receives a command to evoke the control program The program generates a statistically accurate timing of the sampling input and the control output via the electrical interface; wherein the variation in the range of 99.99 percent of the variation distribution between the target time and the actual time is less than or equal to 5 (five) At the millisecond, the sample input and the control output are considered to have statistically accurate timing. The method of claim 1, wherein the control program is prepared in an interpreted programming language. The method of claim 2, wherein the loading of the control program is performed by load processing priority, which maintains the priority of the processing command of the program I/O controller. The method of claim 3, wherein the loading of the control program is further performed without causing the program I/O controller to take off at least some of the input of the sample via the electrical interface and the output of the control. The method of claim 1, wherein the input of the sample and the output of the control are less than or equal to 3 (three) milliseconds in a range of 99.99 percent of the distribution of the variation between the target time and the actual time. The method of claim 1, wherein the input of the sample and the output of the control are less than or equal to 1 (one) milliseconds in a range of 99.99 percent of the distribution of the variation between the target time and the actual time. The method of claim 1, further comprising the program I/O controller transmitting, by the electrical interface, a virtual digit signal corresponding to the input of the sample and the changed output to the tool host without interrupting the sampling and Statistically accurate timing of the control. The method of claim 7, wherein the virtual digit signal comprises a time stamp. The method of claim 7, further comprising the tool host, responding to the virtual digit signal, sending a command to the program I/O controller, causing the program I/O controller to stop running the control program. The method of claim 1, further comprising the program I/O controller transmitting a control command to another program I/O controller, the control program being returned to the statistically accurate timing. For example, the method of claim 1 of the patent scope further includes The tool host indicates the timing tolerance of the control step and causes the tool host to determine whether to delegate the timing of the control step to the program I/O controller by preparing and loading the interpreted control program. A method of controlling a program operating in a processing chamber at repeatable intervals using a program I/O controller in cooperation with a central controller, the method comprising: monitoring and controlling one or more states of operation of the processing chamber The program I/O controller receives the control command from the central controller and processes the control command within a first statistically repeatable short interval of five milliseconds or less after receiving; wherein When the time in the range of 99.99 is less than or equal to the short interval, the short interval is considered to be statistically repeatable; under statistical reproducibility in the process of not losing the control command, the sample is coupled to the Processing one or more sensors in the processing chamber and buffering the sampling within a statistically repeatable tolerance of the sampling schedule; and wherein in the range of 99.99 percent of the distribution of the variation between the target time and the actual time The tolerance is considered to be statistically repeatable when the variation is less than or equal to the tolerance. The method of claim 12, wherein the first statistically repeatable short interval is 3 milliseconds or less. The method of claim 12, wherein the first statistically repeatable short interval is 1 millisecond or less. For example, the method of claim 12, wherein the statistical The repeatable tolerance is 5 milliseconds or less. The method of claim 12, wherein the statistically repeatable tolerance is 3 milliseconds or less. The method of claim 12, further comprising buffering the time stamp corresponding to the sampling. The method of claim 12, further comprising the statistical I/O controller distributing the at least some of the buffered samples without losing the statistical reproducibility of the processing of the control command or the statistical loss of the sampling Repeatability. The method of claim 12, further comprising: controlling the I/O from the program without losing statistical reproducibility of the processing of the control command or losing statistical reproducibility of the sample The memory of the device dynamically executes a loadable instruction; wherein the instruction includes a selected result that should be sampled, the response occurring within a second statistically repeatable short interval, the second statistically repeatable short interval being less than The sample is reported to the central controller and the statistically repeatable feedback interval required to receive the responding command from the central controller. The method of claim 12, further comprising: controlling the I/O from the program without losing statistical reproducibility of the processing of the control command or losing statistical reproducibility of the sample The memory of the device dynamically executes a loadable instruction; wherein the instruction includes a selected result that should be sampled, the response being less than one of the first statistically repeatable short interval and a second statistically repeatable short Occurs within the interval. The method of claim 20, wherein the second statistically repeatable short interval is less than one fifth of the first statistically repeatable short interval. The method of claim 20, further comprising the program I/O controller receiving, identifying, and dynamically loading instructions to the memory of the program I/O controller without controlling the program I/O The monitoring and control aspects of the operation from the processing chamber are off-line. The method of claim 20, further comprising the program I/O controller distributing at least some of the buffered samples without losing statistical reproducibility of receiving and processing the control command or losing the sampling Statistical reproducibility or loss of statistical repeatability of the instructions that perform dynamic loading. The method of claim 12, further comprising: from the program I without losing statistical reproducibility of receipt and start processing of the control command or losing statistical reproducibility of the sample The memory of the /O controller dynamically executes the loadable instructions; wherein the instructions include at least one particular aspect of closed loop control that begins operation of the processing chamber, the beginning being less than the first statistically repeatable short interval Half of the second is statistically reproducible within a short interval. The method of claim 24, wherein the second statistically repeatable short interval is less than one fifth of the first statistically repeatable short interval. The method of claim 24, further included in the program I/O controller, receiving, discriminating, and dynamically loading the loadable fingers The memory of the program I/O controller is taken offline without the monitoring and control aspects of the program I/O controller being operated from the processing chamber. The method of claim 24, further comprising the program I/O controller distributing at least some of the buffered samples without losing statistical reproducibility of receiving and starting processing of the control command or losing the sampling Statistical reproducibility or loss of statistical reproducibility of the execution of dynamically loadable instructions. A program I/O controller comprising: communication with a central processing unit; memory; logic coupled to the memory and the memory and resources, which are capable of receiving control commands from the central controller and receiving five The control command is processed in a first statistically repeatable short interval of milliseconds or less; wherein when the time in the range of 99.99 percent of the time distribution is less than or equal to the short interval, the short interval is considered statistically Repeatable; and capable of sampling one or more sensors coupled to the processing chamber and being statistically repeatable in the sampling schedule under statistical reproducibility in the process of not losing the control command The sampling is buffered within the tolerance; and wherein the tolerance is considered to be statistically repeatable when the variation in the range of 99.99 percent of the distribution of variation between the target time and the actual time is less than or equal to the tolerance. The controller of claim 28, wherein the program I/O controller further distributes at least some of the buffered samples without losing statistical reproducibility of the processing of the control command or losing the fetching Statistical reproducibility. The controller of claim 28, wherein the program I/O controller is further capable of dynamically executing a loadable instruction from a memory of the program I/O controller; wherein the instruction includes a selected one that should be sampled As a result, the response occurs within a second statistically reproducible short interval that is less than one-half of the first statistically repeatable short interval. The controller of claim 28, wherein the program I/O controller is further capable of dynamically executing a loadable instruction from a memory of the program I/O controller; wherein the instruction includes starting the operation of the processing chamber At least one specific aspect of closed loop control, the beginning of which occurs within a second statistically reproducible short interval that is less than one of the first statistically repeatable short interval.