Crossing Automation

Automation Technology As I See It: Roy Wang

In my 15 years of experience as a customer of robotics and wafer automation products prior to joining Crossing Automation, I participated in quite a few equipment design tasks that required integrating many components, modules, and subsystems in a number of areas including motion control, laser and charged beam optics, photoelectric sensing and data acquisition, image formation and processing, as well as network communication. Multiplied by the often multi-source qualification, I had numerous opportunities to observe the range of practices from suppliers. Often, software integration became costly in terms of both the effort required as well as time to market delays due to problems in the software supplied by a vendor.

In my experience, four types of problems topped the list. First, the supplied component exposed the low-level rudimentary control while the application was interested in high level functionality. Second, a small number of functions needed for normal daily operations by the application were mixed with a large number of functions that were only needed for tool building and field service. Third,interoperability was particularly difficult due to the lack of coherence among component suppliers, for example, interlock signals between modules rarely existed. Fourth, the supplied software interface often used out-of-date technology, or implemented cumbersome mechanisms that burdened application integration.

Crossing's products directly address these issues. We leverage the latest technologies in our product development and apply the following principals to our designs:

• Division of responsibility between tool control and module control. Each module exposes its top level functionality as a set of simple application programming interfaces (API) to the tool controller.
• The application software that controls the tool can accomplish a top level task with a single line of code by invoking an API method on the module, without deep knowledge of the details.
• The software embedded in the module's controller implements each API method by encapsulating the complexity of the task, including the real-time control of multiple hardware components, state transitions and interlock signals.

This division of responsibility greatly reduces the burden on the tool control software, and therefore, reduces the cost of integration.

• Division of responsibility between tool application and module service. Each module's lower level functionality is accessible for service use cases, although they are not needed in normal operation of the tool.
• The service interfaces are separate from the application interfaces because the tool application does not use them.
• Crossing provides a user friendly service application that empowers service personnel to have full access to the hardware.

This division of responsibility ensures that the reduced scope of tool integration does not compromise a customer's ability to service a module.

• Division of responsibility between modules. The responsibility of each module is not only defined by its top level interfaces exposed to the tool, but also by its interfaces to other modules specified in the following areas:
• Mechanical interfaces are compliant with industry standards, including material load port, vacuum chamber slot valves, etc.
• Electronic interfaces are specified according to industry standards, including interlocks to ensure operator, material and equipment safety.
• Software interfaces included in the API also provide the tool control application access to the inter-module safety interlocks.

This division of responsibilities ensures that the modules are truly inter-operable building blocks, meaning that tool designers can organize them in a Lego®-like fashion to achieve lower product cost and faster development cycle times.