Industry News, Trends and Technology, and Standards Updates

Meet Jesse Lopez, a member of the Solutions Engineering team. Read on to learn a little bit more about Jesse.

How long have you been working at Cimetrix?

I have worked at Cimetrix since August 2017             

Where did you go to school and what did you get your degree in?

I received my BS in Computer Science from National University.  I'm currently working towards my Masters in Computer Science at National University as well.  I also completed AEGIS Computer Network Training while in the Navy.  I also have an Associate's of Science from Utah State University. 

What brought you to Cimetrix originally?

I worked at IM Flash Technologies as an Engineering Technician.  After getting my Bachelor's in CS I saw a job posting with Cimetrix that perfectly fit my unique background. 

What do you like most about your job?

The satisfaction of solving problems with a proactive support team.

What do you think it means to provide great customer support?

I think that great customer support means listening to understand and not just to hear. Once you can fully understand the customers problem, then you can help provide an effective complete solution.

What’s the biggest accomplishment you’ve had at Cimetrix?

Being able to provide training to new team members and clients.

How do you deal with challenges that come up at work?

I try to use all of the resources I have to figure it out myself. If it is time sensitive or I have spent too much time on it then I will run it by the rest of the CT&S team.

What’s your favorite vacation spot?

Sydney, Australia. 

What's something you’ve learned while working at Cimetrix?

Multi-threading and working with COM objects.

What do you like to do in your free time?

Spend time with my wife and three sons. I enjoy teaching my sons how to fix what they break and how to create what they imagine.

I remember as a new Boy Scout, we planned a hiking trip up into a primitive area in the mountains near my home. One of the first things we learned about reading a map was where to find the legend. The map legend contains important information needed to read a map, like indicating which direction is north. Now that we knew where to find the legend, we could orient the map so it made sense as we were planning our hike.

Most equipment in a typical semiconductor or electronics assembly factory has a user interface that contains a lot of information about the equipment. Most equipment also contains many screens that are used for controlling or operating the equipment. With the use of GEM, a factory host system can control the equipment and collect important data generated during processing.

Like a map, there is a lot of information available on the user interface of a piece of equipment. It can sometimes be difficult to know where to find the important information the host system needs to properly control and communicate with the equipment. The GEM standards provide guidelines on how critical items on the equipment user interface should be presented and controlled. For example, if the host sends information to the equipment operator about tasks they need to perform, the GEM terminal message guidelines state that the information must remain on the user interface of the equipment until the operator acknowledges that they have read it.

The SEMI E30 standard defines the Specification for the Generic Model for Communications and Control of Manufacturing Equipment (GEM). In addition to providing the definition of the common set of equipment behavior and communication capabilities required for manufacturing automation, the standard also provides requirements on which items must be present on an equipment user interface and how they should be represented. User interface requirements spelled out by the standard address communication state, terminal service new message indicator, terminal services message recognition button, communications state default and communications state selector.

This may seem like a small thing, but just like knowing where to find the legend on a map enabled understanding of the lines and symbols on the map, so too the GEM standards can help provide an understanding of information presented on an equipment interface that is essential for communication with a factory host system.

Click here to read the other articles in our SECS/GEM Features and Benefits series. 

To download a white paper on an introduction to SECS/GEM, Click below:

Meet Ian Ryu, a member of the Solutions Engineering team in Korea. Read on to learn a little bit more about Ian.

How long have you been working at Cimetrix?

I started in May 2016 and have been here for two years now. 

Where did you go to school and what did you get your degree in?

I got my BS in electronics/electrical engineering in Korea.

What brought you to Cimetrix originally?

Cimetrix was looking for an engineer who can speak Korean for the Korean market. 

What do you like most about your job? 

The people, especially our leadership team. I have strong trust and pleasure working with people here.
I also have strong confidence that I am improving my skills as a software engineer

What do you think it means to provide great customer support?

Making customers happy.  By doing that we will grow together for mutual success.

What’s the biggest accomplishment you’ve had at Cimetrix? 

Becoming a better engineer with my team. I’ve been learning and improving myself with them.

How do you deal with challenges that come up at work?

I've tried to develop myself for when these situations come up. I have colleagues who are experts in each product, too

What’s your favorite vacation spot? 

I enjoy camping with my family. We went to Mirror Lake and Goblin Valley in Utah many times.

What's something you’ve learned while working at Cimetrix?

Working with honest, hard-working people raises me up with relief

What do you like to do in your free time? 

Playing video games with my children. I can’t forget my 5 year old son beat me on Mario cart!

Yufeng Huang of Cimetrix China, talks about Equipment Control in the factory. Read now in Chinese or below in English.

在和半导体设备制造公司的接触中我们遇到这么一个尴尬的问题，很多懂得设备控制的优秀软件工程师对于GEM，GEM300和EDA标准不是很有经验。这些公司往往是在设备在实验室研发成功，准备产业化送入客户工厂时发现设备没有实现或只有部分实现GEM/GEM300标准，尤其是当客户工厂要求EDA（Interface A）通信接口的时候，这些设备制造商的软件工程师往往一脸茫然，不知道如何在短时间内开发出完全遵循GEM/GEM300/EDA标准的软件。

对于大多数设备公司而言，限制于有限的人力、财力资源，公司很难聘请到足够多富有经验的工厂自动化软件工程师开发自己的GEM/GEM300，甚至EDA软件模块。另外一个棘手的问题是我们发现很多软件工程师不是特别有意愿加入到半导体行业，而是选择比较热门的互联网、游戏，手机App等软件行业。纵观半导体工厂自动化软件市场，虽然已有多家公司提供GEM/GEM300/EDA的软件开发包（SDK），但软件工程师仍旧需要掌握一定的工厂自动化基础知识才能着手编写软件集成代码。工厂自动化涉及大量SEMI标准，譬如GEM标准大概有450页文档，包括E4，E5，E30，E37，E37.1，E172，E173，GEM300标准大概有280页文档，包括E39，E40，E87，E90，E94，E116，E157，E148，而更为复杂的EDA标准大概480有页文档，包括E120，E125，E128，E132，E134，E138，E164，对于大多数非专业的工厂自动化软件工程师而言，工厂自动化软件的集成工作是一件极其繁琐而艰难的任务。

Cimetrix Control Framework^TM (CCF) 是基于微软.Net技术的设备自动化控制软件框架，该软件不仅为设备制造厂商提供了监督控制和生产控制框架代码，而且完全实现了GEM/GEM300/EDA标准。借助CCF软件平台，软件工程师无需深刻掌握工厂自动化的所有SEMI标准，就能轻松变身为工厂自动化开发专家。CCF软件框架内的工厂自动化模块基于Cimetrix公司的CIMConnect，CIM300，CIMPortal Plus三个独立的软件开发套件（SDK）实现，分别对于实现GEM，GEM300，和EDA标准。全球任意一家300mm的芯片制造工厂都有安装了CIM300软件的设备运行，在支持EDA数据采集的工厂都有安装了CIMPortal Plus软件的设备运行。CCF软件框架将所有工厂自动化的开发工作交给Cimetrix公司来完成，设备软件工程师可以把更多的时间花费在如何设计自己的设备控制软件上。

在CCF框架下，CIMConnect/CIM300/CIMPortal Plus的底层API函数都被很好作了封装，软件工程师只需通过CCF框架提供的函数或接口就能轻松实现和工厂主机程序的所有GEM/GEM300标准。实现EDA标准的一个重要任务是创建一个支持分层次结构的设备模型，以及按照标准生成XML数据，此外生成的模型还需满足E164标准。在CCF软件初始化运行时会动态生成设备模型，软件工程师几乎不需要书写EDA代码，设备即可很好的遵循EDA标准。

采用CCF软件框架降低设备控制程序和工厂自动化程序的开发难度和开发周期，但并不意味着我们的客户一定得推翻自己已有的软件平台或已经测试过的稳定代码。CCF是一个提供源代码的完全开放的自动化控制程序框架，你可以将CCF理解成一个已经拼好的乐高玩具，用户既可以将自己的代码模块集成到CCF中，也可以挑选部分CCF功能模块并将其转移到用户自己的框架中。我们用户将CCF中工厂自动化模块（包括GEM/GEM300/EDA）搬迁到自己的程序框架中，在保证完全遵循工厂自动化诸多SEMI标准的同时，对用户已有程序的影响非常小。

得益于CCF框架的完全开放性，像玩乐高积木一样，软件工程师可以轻松享受自由裁剪自己想要的控制系统框架带来的乐趣，这是其他任何一家提供设备控制软件框架程序的公司都很难做到的一件事情。

在未来几年，越来越多的工厂往智能生产制造的方向发展，由此对数据的需要越来越高，EDA标准越来越成为工厂主流的数据采集方法，CCF无疑成为了设备制造商更快更好实现各种工厂自动化标准的最佳武器。 

---

We encountered an interesting issue when working with semiconductor equipment manufacturing companies. Many excellent software engineers who know equipment control are not very experienced with the GEM, GEM300, and EDA standards. Sometimes after equipment is successfully developed in the laboratory and before the equipment is shipped to the factory, we discover that the equipment did not implement or only partially implemented the required GEM/GEM300/EDA standard. This is especially prevalent when the factory requires the EDA (Interface A) communication interface. Equipment software engineers sometimes do not know how to develop software that fully complies with GEM/GEM300/EDA standards in a short period of time.

For most equipment companies with limited human and financial resources, it is difficult for the company to have the resources to develop their own GEM/GEM300/EDA software. Another issue is that we have found many of the more experienced software engineers are more interested in high-profile  internet, gaming, mobile phone apps and other software industries rather than the lower profile semiconductor industry.  Although many companies in the semiconductor factory automation software market have provided GEM/GEM300/EDA software development kits (SDKs), software engineers still need to master certain basic knowledge of factory automation to start writing software integration code. Factory automation involves a large number of SEMI standards. For example, the GEM standard has about 450 pages of documents, including E4, E5, E30, E37, E37.1, E172, E173. GEM300 standards have about 280 pages of documents, including E39, E40, E87, E90, E94, E116, E157, E148. The more complex EDA standard has about 480 pages, including E120, E125, E128, E132, E134, E138, E164. For less experienced factory automation software engineers, the integration of automation software can be an extremely tedious and difficult task.

Cimetrix CIMControlFramework^TM (CCF) is an equipment automation control software framework based on Microsoft .Net technology. This software not only provides equipment manufacturers with supervisory control and equipment control framework code, but also fully implements the GEM, GEM300 and EDA standards. With the help of the CCF software platform, software engineers can easily turn into factory automation development experts without having to master all the factory automation SEMI standards. The factory automation components within the framework of the CCF software are based on CIMConnect, CIM300, and CIMPortal Plus, three independent software development kits (SDKs) from Cimetrix for the implementation of the GEM, GEM300, and EDA standards, respectively. All 300mm chip manufacturing factories in the world have equipment installed which uses CIM300 software. Any factory requiring EDA data collection has equipment installed that uses CIMPortal Plus software. With the CCF software framework, Cimetrix has already done the work of integrating all factory automation into the framework. The equipment software engineer can spend more time on how to develop their own equipment control software.

Under the CCF framework, the underlying API functions of CIMConnect/CIM300/CIMPortal Plus are well encapsulated. Software engineers can easily implement all the GEM/GEM300/EDA standards of the factory host program through the functions or interfaces provided by the CCF framework. An important task in implementing the EDA standard is to create an equipment model that supports hierarchical structures and generate XML data in accordance with standards. In addition, the generated model must also meet the SEMI E164 standard. The equipment model is dynamically generated when the CCF software is initialized. The software engineer needs to do very little to have an equipment control application that is fully compliant with the EDA standard.

The use of the CCF software framework to reduce the difficulty and development cycle of equipment control programs and factory automation programs does not mean that our clients must replace their existing software platforms or stable code that has been tested. CCF is a fully open automation control program framework that provides source code. You can think of CCF as a LEGO toy that has been put together. Users can either integrate their own code modules into CCF or select some of the CCF functional modules and transfer them to their own framework. Our clients can reuse the factory automation modules (including GEM/GEM300/EDA) in CCF in their own program frameworks. While ensuring that all SEMI standards for factory automation are fully complied with. The impact on the user's existing programs is minimal.

Thanks to the complete openness of the CCF framework, like LEGO bricks, software engineers can easily enjoy the freedom of tailoring the control system framework that they want. It is hard for any company that provides an equipment control software framework program to implement such a rich library of functions. 

In the next few years, more and more factories will move in the direction of smart manufacturing. As a result, the demand for data is getting higher and higher. EDA standards are increasingly becoming the factory's mainstream data collection method. CCF will undoubtedly become the best weapon for equipment manufacturers to quickly and completely implement the various factory automation standards.

In the third article of this EDA Applications and Benefits in Smart Manufacturing series, we highlighted the first of a series of manufacturing applications that leverage the capabilities of the EDA / Interface A suite of standards in leading semiconductor manufacturers. In this fourth article, we’ll highlight the application that has been the principal driver for the adoption of EDA across the industry thus far, namely Fault Detection and Classification (FDC).

Problem Statement

The problem that FDC addresses is the prevention of scrap that may result from processing material by an equipment that has drifted out of its acceptable operating window for whatever reason. The prevalent technique used by today’s leading FDC systems is to develop “reduced dimension” statistical fault models for the various production operating points based on training sets of “good” and “bad” runs. These models are then evaluated in real time with key parameters (usually trace data) collected from the equipment during processing to detect process deviation and predict impending tool failure. In the most advanced fabs, the FDC software is deeply integrated with the systems that manage process flow, and can even interdict equipment operation in mid-run to prevent/reduce scrap production. 

Of course, the challenge with this type of algorithm is developing models that are “tight” enough to catch all sources of potential faults (i.e., eliminating false negatives) while leaving enough wiggle room to minimize the number of false positives (also known as false alarms, or crying “Wolf!”). This in turn requires high quality data from the equipment, and lots of process engineering and statistical analysis expertise to develop and update the fault models for the range of production cases that must be handled. High-mix foundry environments exacerbate this situation.

Solution Components

The core of modern FDC systems is a robust multivariate statistics analysis toolbox, capable of handling large amounts of time series data. By “large,” we mean both the number of distinct equipment parameters and the number of samples for each parameter. These software tools collapse potentially hundreds of parameters into a small set of “principal components” that can be calculated on-the-fly using a limited set (say, 20-30) of equipment parameters. Some number of these principal components in aggregate represent the actual state of the process accurately enough to detect deviations from the norm, and since they can be realistically calculated in real time, the application serves as an on-line equipment health monitor.

The other major solution component for a production FDC system is a fault model library management capability that can handle large numbers of models. This is necessary because the multivariate approach includes little or no awareness of the physical meaning of the principal components (i.e., they are not “first principles” based), so different operating points for the equipment must have their own sets of fault models. The proper models for a given operating point are selected by matching the values of the “context parameters” for a specific run to those used to store the models. Even if some models can be shared across a range of operating points, the number of distinct models for a foundry megafab will still number in the thousands.

EDA (Equipment Data Acquisition) Standards Leverage

In an advanced fab, there is a spectrum of data collection alternative available for a given application, from basic lot-level summary information to detailed real-time data that can used at the substrate level or even on a die/site basis. For FDC, this spectrum of possibilities is shown in the table below.

SEMI Standard Level	Functionality	Benefit
GEM/GEM300	Fault models difficult to change after initial development if data collection requirements change	Baseline
EDA Freeze I (1105)	Easy to change equipment data collection plans as fault models evolve and require new data; Model development environment can be separate from production system	Engineering labor reduction; improved fault models and lower false alarm rate
EDA Freeze II (0710)	Use conditional triggers to precisely “frame” trace data while reducing overall data collection needs; Incorporate sub-fab component/subsystem data into fault models	Even better fault models; reduced MTTD (mean time to detect) of fault or process excursion; little or no data post-processing required
EDA Common Metadata (E164)	Include standard recipe step-level transition events for highly targeted trace data collection; Automate initial equipment characterization process by using metadata model to generate required data collection plans	Faster tool characterization and fault model development time
Factory-Specific EDA Requirements	Incorporate previously unavailable equipment signals in fault models; Update data collection plans and fault models automatically after process and recipe changes; Include recipe setpoints in the equipment metadata models	TBD (Not yet applicable)

 

The left column refers to the level of SEMI standards used to provide the necessary equipment data. The “Functionality” column describes how that data is used in an FDC context, and the “Benefit” column highlights the potential impact these functions can have. 

Let’s say that a fab implemented the capability described on rows 3 and 4 of the table (EDA Freeze II (0710) and E164-compliant EDA Common Metadata). In this case, the process equipment will be able to provide detailed process parameters at recipe step-specific sampling rates sufficient to evaluate “feature extraction” algorithms of even the most demanding FDC models…with context data to select the precise set of models for a given process condition. And even though the specific equipment parameters are necessarily process dependent, much of the software that monitors recipe execution events, generates the data collection plans (DCPs) that provide the trace data, and assembles the context data used by the model management library can be truly generic because of the fab-wide consistency of the equipment interfaces dictated by the E164 standards.

Another aspect of the EDA standards that FDC teams can leverage is the system architecture flexibility enabled by the multi-client capability. Even while a piece of equipment is connected to a production data management infrastructure, the process engineers and statisticians who develop and refine the fault models can use an independent data collection system tailored for process behavior analysis, experimentation, and continuous improvement. When the new fault models are ready for production, the production DCPs can be updated with these new requirements.

KPIs Affected

After several articles in the series discussing data collection, events, alarms, recipe management and documentation, this post focuses on the Twitter of the GEM standard – Equipment Terminal Services. We will examine what terminal services are, why they are needed and the mechanics of how they work.

What are Terminal Services?

Equipment Terminal Services allows the factory operators to exchange information with the host from their equipment workstations. The host can display information on the equipment’s display device. It also allows the operator of the equipment to send information to the host. The equipment must be capable of displaying information passed to it by the host for the operator’s attention. 

Why Do You Need This Feature?

An example of when terminal services might be used is as follows:

1. The host gets notified by the FDC software that the process module had an excursion that needs to be addressed.
2. The host turns on an operator notification light on the light tower. The notification light needs to be accompanied by a reason that the light was illuminated.
3. The host sends a terminal message saying that the FDC software detected an excursion and that the operator should address the issue.
4. Along with the signal tower light, the terminal services notification is active on the tool.
5. The operator sees and acknowledges the message.
6. Optional: There are different ways to recover, but the operator could send a terminal message to the host after the issue is resolved.

How Does Terminal Services Functionality Work?

When the host sends a terminal message to the equipment, the equipment is required to display the message to the operator. The display must be able to show up to 160 characters (even more than can be sent in a single tweet using Twitter) but may display more than that. The equipment’s display device must have a mechanism for notifying the operator that a message was received and not yet recognized by the operator. The message continues to be displayed until the operator recognizes the message. The equipment must provide a method, such as a push button, for the operator to acknowledge the message. Message recognition by the operator results in a collection event that informs the host that the operator has received the information. The equipment application is not required to interpret the data sent from the host. It is solely information meant for the operator.

If the host sends a new message is sent before the operator acknowledges a previous message, the new message overwrites the previous message.

The host may clear unrecognized messages (including the indicator) by sending a zero-length message. The zero-length message is not considered an unrecognized message.

The equipment must also allow the operator to send information entered from the operator’s equipment console to the host. 

Which messages are used?

Message ID	Direction	Description
S10F3	H->E	Host sends textual information to equipment for display to the operator on a terminal
S10F1	H<-E	Operator sends text message to host
S10F5	H->E	(Optional) Host sends multi-block display message. If multi-block is not supported, the equipment responds with an S10F7 message that multi-block is not allowed.
S6F11	H<-E	Equipment sends collection event to the host notifying the host that it has recognized the message

 

Click here to read the other articles in our SECS/GEM Features and Benefits series. 

To download a white paper on an introduction to SECS/GEM, Click below:

Meet Mark Bennett, a member of the Solutions Engineering team. Read on to learn a little bit more about Mark.

How long have you been working at Cimetrix?

I have  been with Cimetrix for over 15 years. I started back when Cimetrix was primarily involved with robotics.

Where did you go to school and what did you get your degree in?

I went to Brigham Young University, and got a B.S. degree in Mechanical Engineering.

What brought you to Cimetrix originally?

At the time, I was working in the HVAC (Heating Ventilating and Air Conditioning) industry as a Mechanical Engineer. This was my first job out of college, and I decided that I didn’t want to make HVAC my career choice.  I got introduced to Cimetrix by my brother, who was working with Cimetrix as a customer.

What do you like most about your job?

I like solving problems and learning new things. What we do is not rocket science, but it’s probably just about as challenging.

What do you think it means to provide great customer support?

Solve customer issues and help them successfully get their equipment deployed.

What’s the biggest accomplishment you’ve had at Cimetrix?

A few years ago, I was sent to TSMC in Taiwan to help a customer get a tool accepted in the FAB. They were having problems getting the E84 automated material handling system working. It was a very difficult assignment because the tool was already installed in the FAB and there were a lot of problems to fix. The FAB only allowed us to perform one or two tests per day. So, I captured log files from the tests, went out to the parking lot, and made code changes in the car. To fix the problem, I pretty much had to rewrite the entire E87 AMHS handling code, and a lot of the load port code as well.

How do you deal with challenges that come up at work?

Most of the challenges I face involve solving issues that customers report. Here are some things that I might try:

• Reproduce the problem using a sample application. Try to identify if this is a problem with the product, or if the customer is not using it properly.
• Search our database to see if this issue has been reported before. Find out how it was resolved in the past.
• Look through the SEMI standards to see how it should behave.
• Look through product documentation and release notes.
• Ask others for their opinions/suggestions.

What’s your favorite vacation spot?

Lately, we have been staying close to home for vacations.  We have taken trips to the San Francisco Bay area.  We enjoy that.

What's something you’ve learned while working at Cimetrix?

I’ve learned a lot about the SEMI standards. I have also learned a lot about software development and programming.

What do you like to do in your free time?

I enjoy watching movies. I also like trying to perfect my cooking skills on my Kamado barbecue grille.

Meet Tami Tracey, Manager of Solutions Engineering. She's been with Cimetrix for six years and has been a significant contributor in her position. Read on to learn a little bit more about Tami.

Where did you go to school and what did you get your degree in?

I went to the University of California at Irvine and graduated in Computer Science. During my undergraduate degree I was more interested in circuits and robotics. When I moved to the Bay area, I was drawn to the semiconductor equipment manufacturers in Silicon Valley where software applies to the physical world nearly directly.

What brought you to Cimetrix originally?

I worked in control systems software development on semiconductor front-end equipment for more than a dozen years, which from time to time touched on factory communications. A work colleague mentioned an opening and I liked the idea of working on software that integrates the equipment and the factory.

What do you like most about your job?

Debugging. Diagnosing problems feels like part-logic, part-archaeology, and part-intuition, and it is a fun place for my brain.

What do you think it means to provide great customer support?

Listening carefully to clients, learning their use cases and concerns, and advocating for their needs when it comes to product improvements

What’s the biggest accomplishment you’ve had at Cimetrix?  

The most memorable client “issue” lasted more than a year and required both technical analysis of incident logs, product testing, and sustained project management. We were successful helping the client, and I earned the respect of their engineering lead.

How do you deal with challenges that come up at work?

I keep an eye on the big picture. Hard work is hard work and can’t be avoided, so I prefer to dig in and get it going. I also have a practice of summarizing any particular incident for myself, so that I can be clear on what was learned and be able to return to that analysis later if needed.

What's something you’ve learned while working at Cimetrix?

Cimetrix is a growing company and its value system is really led by the executives. The company has challenged itself to improve internally, and the culture embraces both change and respect. I’ve learned a lot about myself, others, and ‘organizations’ in this time.

What’s your favorite vacation spot?

Switzerland, because of the Alps.

What do you like to do in your free time?

I volunteer for a local non-profit involved in education about emergency preparedness; last year I helped the organization get their non-profit status. I also have played frisbee sports for a long time, and I help run a disc golf tournament for women where I am responsible for sponsorship, social media marketing, and event operations.

In the introduction to this series (posted December 19, 2017), we listed some of the manufacturing stakeholders whose work objectives are directly addressed by the applications we’ll highlight in this and subsequent postings. In the second article, we explained the process used to map the careabouts of key stakeholder groups into specific EDA interface requirements which are can then be directly included in the purchasing specifications. 

In this post, we’ll explain how some of those interface requirements support an important factory application that has general applicability across all equipment types, namely “real-time throughput monitoring.” This application can realistically work with a variety of equipment types with no custom code or configuration depending, of course, on how faithfully the equipment supplier implements the SEMI standards referenced in the requirements specification. This powerful concept greatly improves the software engineering productivity of a fab’s automation team, so we’ll take some time to explain how this is possible.

Problem Statement

This application addresses the problem of monitoring equipment throughput performance in real time, and raising an alarm when it drifts away from “normal” for any reason. This is especially important for bottleneck equipment (e.g., litho tracks and scanners), because any loss of throughput ripples throughout the line, resulting in lost production and its associated revenue and profit. Stated simply, “lost time on a bottleneck tool can never be recovered.” 

Solution Components

This application requires data that includes primarily the equipment events that chronicle the movement of substrates through the equipment and execution of the recipes appropriate for this equipment type (process, metrology, inspection, sorting, etc.). With this information, the application calculates the process time “on the fly” and compares the current value with the expected (“normal”) value. 

This is not as simple as it first may seem, because the expected value will likely depend on the product type, process type, material status, layer, recipe, and several other factors. Taken together, the set of factors that determines “equivalence” of different lots for some processing purpose is called “context.” For this application, the context parameters ensure that you are comparing apples and apples when looking for variations in process time.

EDA (Equipment Data Acquisition) Standards Leverage

By “EDA,” we include not only the standards in the Freeze II / 0710 suite, but also SEMI E164 (EDA Common Metadata), E157 (Module Process Tracking), and by reference, the entire GEM 300 suite. This ensures not only the granularity and breadth of event support necessary to precisely track wafer movement and step-level recipe execution, but also specifies the naming conventions of those events and their associated parameters, regardless of equipment type or vendor.

If the equipment automation purchase specifications include clauses that state “we require that all state machines, states, state transition events, and attributes of the objects defined in the referenced 300mm SEMI standards be implemented and named exactly as specified in the standards,” then all the information you should need to write a truly generic throughput monitoring application will be available on demand.

A robust real-time throughput monitoring algorithm can be implemented with information solely from the following SEMI standards: E90 (Substrate Tracking), E157 (Module Process Tracking), E40 / E94 (Processing / Control Job Management), and E87 (Carrier Management). The Harel state diagrams, events of interest, and EDA metadata model representation* for a couple of these (E90 and E157) are shown in the figures below.

Note that as little or as much of the parameter information required to be available for each event (the rightmost picture in each figure) can be collected via the EDA construct of a “Data Collection Plan” (DCP) with one or more “Event Requests.” For more information about these capabilities, consult the SEMI E134 (Data Collection Management) specifications directly, or review some of the extensive educational material available on our web site.

The other point of leverage for the EDA standards is the multi-client capability. This contributes to the productivity and responsiveness of your automation software team members by allowing them to collect and process the data for this application independently from any other application. Specifically, the throughput monitoring functions can be implemented separately from whatever systems host the GEM command and control capabilities, which are usually managed very carefully because of their potentially negative impact on fab operations.

Key ROI Factors

As we said in the initial post of this series, this application is not just something you could build and deploy with EDA-enabled equipment… in fact, this has already been done, and is delivering real production manufacturing benefit! Specifically, the ROI factors impacted (and benefit delivered) by this application include productivity excursion mean-time-to-detect (MTTD, 50% reduction), selected equipment throughput improvement (3-5%), and overall cycle time reduction (difficult to quantify precisely because of the staged implementation process). 

Of course, these results will vary depending on the manufacturer’s fab loading, operations strategy, and overall automation capabilities, but are representative for leading edge production wafer fabs running at near capacity. However, since these are very common ROI factors, most companies can easily quantify these improvements in real financial terms.

In Closing...

As always, your feedback is welcome, and we look forward to sharing the Smart Manufacturing journey with you.

*The visualizations of equipment metadata model fragments are those produced by the Cimetrix ECCE Plus product (Equipment Client Connection Emulator).

Let us know if you would like to schedule a meeting to learn more:

SEMICON China was held from March 14-16, 2018 in Shanghai at the Shanghai New International Expo Centre. Simultaneously co-located at this huge complex were Productronica China and Laser World of Photonics China. All three shows were very busy this year, and it is clear the electronics manufacturing industry in China is booming.

Cimetrix attendees included Dave Faulkner (VP Sales and Marketing), Ranjan Chatterjee (VP Smart Factory Business Unit), Michael Lee (Country Manager Taiwan), Yufeng Huang (Senior Software Engineer), Alan Weber (VP New Product Innovations), and Kimberly Daich (Marketing Manager); Hwal Song (Country Manager Korea) was also able to attend for one day. The Cimetrix booth was busy throughout the show, and provided a comfortable and convenient setting for the many scheduled and walk-in meetings that took place.

Cimetrix partners Facet and Flagship also attended the show, and participated in several customer/prospect discussions. In conjunction with our partner Facet, Cimetrix software products are now used in more than 25 production factories within the China market segment. Moreover, the relationships we have established throughout the semiconductor and electronics markets are strengthening our global presence and enable Cimetrix to provide local support to current and potential clients. The most recent example is our Shanghai office, opened in 2017.

In addition to the exhibitions, SEMICON China sponsored many forums for expert speakers throughout the show. One of these included the New Technology Release Forum where our own Alan Weber was selected as a speaker. His topic “Integrated Equipment Data Collection and Management for Smart Manufacturing” was well received by those in attendance. Smart Manufacturing has been a topic of keen interest at all SEMICONs over the past 18 months, and China was no exception; a separate forum dedicated to Smart Manufacturing drew a standing-room-only crowd to hear a broad range of speakers across the technology spectrum.

We are currently expanding our Shanghai office in response to the exciting growth opportunities we see for our industry in China, and look forward to many years of collaborative work in this region.