Industry News, Trends and Technology, and Standards Updates

IPC APEX 2020 is almost here, and we are excited to be exhibiting for the fourth year in a row! This year, you can find us at booth #1521 and we hope to see you during the show!

IPC APEX is the largest event for electronics manufacturing in North America. You’ll find exhibitors and attendees from around the world come not only for the exhibition, but also to participate in standards development, a technical conference and professional development.

We are happy to announce that Ranjan Chatterjee, the Cimetrix VP & GM of the Smart Factory Business Unit will be speaking, along with Dan Gamota from Jabil, on Wednesday between 10:30 – 12 Noon.

One unified platform to run your entire factory

The IPC APEX Show runs Tuesday, February 4 – Thursday, February 6 at the San Diego Convention Center, San Diego, CA, USA.

If you would like to learn more about how Cimetrix software products can help with your Smart Factory goals, please stop by our booth #1521 during the show. You can also request a meeting any time on the events page of our website by clicking the Schedule a Meeting button below. We look forward to seeing you in San Diego!

Background

Several years ago, I was working with a client implementing EDA who wanted to collect data at higher than typical rates using the EDA trace data collection feature (essentially periodic data polling). The typical EDA data collection rate I was used to was 10 Hz, with a couple of clients implementing 20 Hz or even 40 Hz. This client, however, wanted to collect data at about 1000 Hz. This was a lot faster than we normally could accomplish, especially since the software timers and clock functionality in Windows are really designed for about 15 ms intervals. Therefore, the normal means of implementing the data collection was not going to work very well.

With a little creative thinking, I came up with a solution. Instead of using trace data collection, I decided to try event data collection. Every 1 second, I triggered an event notification and provided 1000 data samples with the event that had been collected at 1 ms intervals and stored. The 1000 samples were presented to the EDA client as an array of data, which EDA supports directly, and this solution worked very well. I also found that this approach used surprisingly few resources to implement and transmit, largely because the data is so compact. It was also very reliable.

Although this event with array data solution worked in this very specific situation, there were a few drawbacks. First of all, the client could not choose the data collection interval. Normally with trace data collection the client chooses the data collection rate to meet the needs of a specific data collection application. Secondly, the client receiving the data had to know what the data meant. The client application software had to be programmed to understand that each value in the 1000 sample array represented data collected every 1 ms. Finally, I could not use the trace start trigger and stop trigger to automatically enable and disable the reporting of the data collected. Normally, trace data collection can be started and stopped automatically to collect data between specific equipment events, which is a nice feature to focus data collection between specific processing steps or other meaningful activities.

EDA Freeze 3

A couple of years ago, the SEMI North America DDA (Diagnostics and Data Acquisition) task force, which I co-lead, decided to begin work on the next version of the EDA standards suite, commonly referred to as EDA Freeze 3. As part of this work, I raised an issue that I wanted our task force to address. That is, I wanted to be able to collect data using the EDA standard at higher frequencies than the typical 10 Hz available using today’s trace data collection. In particular, I wanted to leverage what I had learned using the event data array solution to report data collection at 1000 Hz and faster, and make this an integral part of the EDA standard without the limitations of my current solution. This new feature is now called Cached Data.

Cached Data Features

The basic principle behind this new feature is simple. First, allow the EDA client to define a Cached Data Request and specify the reporting frequency, data collection frequency, and other attributes like the number of samples, a start trigger, a stop trigger, and whether or not the triggers are cyclical. Then have the EDA server report the data for each parameter as a compact data array.

For example, an EDA client might ask for a parameter at a collection interval of 0.1 ms (10 KHz) and a reporting interval of 1 second. The result would be a set of Cached Data Reports that look like this:

The equipment would collect the data every 0.1 ms and store the values for 1 second, and then send the Cached Data Report with the collected values in a tightly packed array. The EDA client would receive the data once per second and would know the data collection frequency.

Limitations

There are some limitations to the Cached Data proposal. For example, this type of data array reporting is only practical for some data types like integers, floats, Booleans and bytes. This type of data reporting is not practical for structured data or strings. Moreover, not all data can or should be collected at such high rates. Collecting data at these high rates requires robust software specifically designed for high-speed data collection. Therefore, the EDA proposal includes a way for parameter metadata to specify where the cached data feature can be used, and includes the specific minimum and maximum data collection frequencies. Therefore, the Cached Data feature is expected to be used for a limited subset of the available parameters for which the EDA server is specifically designed to provide such high-speed data collection.

gRPC & Protocol Buffers

The proposed EDA Freeze 3 standards also include the use of gRPC and Protocol Buffer technology, thereby moving EDA away from SOAP/XML over HTTP. gRPC with Protocol Buffers is a solution for a binary interface. Prelimiary test results reported to the DDA task force show dramatic throughput improvements and reduced bandwidth requirements for EDA. Additionally, the testing confirmed that reporting data in compact arrays is far more efficient for transmitting large amounts of data. In other words, the Cached Data feature is expected be even more effective due to this EDA protocol change.

SEMI Voting

Soon a new voting cycle for SEMI standards will begin where we vote on new versions of the standard. The Cached Data feature is included in two SEMI ballots: ballot 6553, a major revision of the SEMI E134 SPECIFICATION FOR DATA COLLECTION MANAGEMENT, and ballot 6527, a major revision of the SEMI E125 SPECIFICATION FOR EQUIPMENT SELF DESCRIPTION. Both are planned for voting in SEMI voting cycle 2 in 2020. Task force members are currently reviewing the latest revision of the proposed ballots.
Studies have already shown vast improvements in factory applications when collecting data at 10 Hz instead of 1 Hz. The increased performance of EDA Freeze 3 will allow the industry to dramatically improve manufacturing processes even more when data can be collected and reported at rates of 1000 Hz, 10 KHz, and beyond.

As a young boy, I liked to work on the family car with my dad. He taught me how to change the oil, check the spark plugs, replace the shock absorbers, adjust the timing and lots of other tasks that were common on older cars. I remember the first time he let me use the socket wrench. I thought it was the greatest tool ever invented. I could loosen bolts, then moving a small switch into a different position, the same wrench could now tighten bolts. It is a very versatile tool, one I still make sure to have handy to this day. 

I appreciate having well-designed tools available that can be used in a variety of situations. In my career, these tools have sometimes been software tools. I have spent a lot of my career working with equipment connectivity standards and seeing the benefits of having process equipment connected to a factory control system. Whether it is for full equipment control, or just to monitor and gather data from the equipment, having a robust connection to equipment is valuable.  

When I first started connecting equipment to factory control systems, the GEM standard had not been finalized. There was a lot of variability in the SECS message implementations available from the different equipment vendors. I was almost always able to get the equipment connected to the factory system, but generally each connection was custom to that equipment vendor and equipment type. This meant that each connection took far too much time to complete and made supporting different equipment very difficult. 

Once the GEM standards were finalized and adopted, there was now a versatile way to provide consistency and reusability across equipment types and across equipment vendors. Connecting to different types of equipment was principally a configuration task instead of a custom coding task.  

In addition, industry standard compliance test tools were developed to ensure compliance with the GEM standards and harden the implementations for reliable production use. This increased reliability helped drive the adoption and implementation of GEM in the global semiconductor front-end manufacturing industry. As a result, GEM has become a well-established reliable communication standard that is widely used and accepted.  

As other segments of the semiconductor and related electronics manufacturing markets have looked to connect equipment to their factory control systems, many have evaluated GEM and other communication standards to provide this functionality. In some cases, GEM was considered too old, too complex, or not a good fit. But, like the versatile socket wrench, many industry segments have seen the value of the stability and proven nature of GEM. They found that the socket wrench (GEM) was the right tool—they just needed a different sized socket (industry-specific guidance) to fit their needs. Let’s look at a few examples.  

SEMI PV2 

In 2007, when the photovoltaic industry wanted to increase manufacturing efficiencies and reduce costs, they looked to implement industry-wide standards. They formed the Photovoltaic Equipment Interface Specification Task Force to define the interface between the factory control system and the equipment. 

The task force created two working sub-teams to evaluate existing solutions and the requirements of the industry. Several existing solutions such as SECS/GEM, EDA, OPC-UA, and XML were evaluated based on functionality, reliability, extendibility, and the ability to be integrated into different environments. The conclusion of both teams was to build on the SEMI GEM (E30) standard.  

The socket wrench (GEM) was the right tool, and a new socket (SEMI PV2) provided the required fit for their equipment and industry. 

HB-LED 

In 2010, when the high-brightness light-emitting diode (HB-LED) industry started their search for connectivity standards. They needed something that would allow low-cost, common hardware and software interfaces, and other means to enable HB-LED factories to effectively utilize multiple equipment types from multiple vendors in a highly automated manufacturing environment. 

This search found that the best course was to leverage the functionality, reliability, and extendibility of GEM. The SEMI HB4: Specification of Communication Interfaces for High-Brightness LED Manufacturing Equipment (HB-LED ECI) defines the behavior of HB-LED equipment and is based on the SEMI E30 (GEM) standard.  

Again, the socket wrench (GEM) was the right tool. What they needed was a socket (HB4) that would meet the needs of their industry. 

PCBECI 

In February 2019, the Taiwan Printed Circuit Association (TPCA) initiated an activity seeking to boost network connectivity of PCB equipment and help PCB makers implement smart manufacturing practices in the industry.  

The result of this effort was the publication in August of 2019 of the SEMI A3: Specification for Printed Circuit Board Equipment Communication Interfaces (PCBECI). This is a robust and comprehensive shop-floor communication standard that specifies the detailed, bidirectional communications needed to improve productivity and reduce the costs to develop equipment interfaces for PCB manufacturing. The SEMI A3 (PCBECI) standard is based on the SEMI E30 (GEM) standard. 

Yet again, the socket wrench (GEM) was the right tool and all that was needed was a socket for their specific needs (PCBECI).  

It is understandable to think of GEM as an old and complex standard. It has been around for years and can be difficult to understand. However, it has continued to be reviewed and updated as manufacturing needs have changed. As different market segments have looked for equipment communication standards to meet their specific needs, several have found that the functionality, reliability, extendibility and the ability to be integrated into different environments provided by GEM was the right tool. All that was needed were some companion specifications related to GEM to provide a better fit for their requirements. 

Cimetrix Korea is happy to announce that the 5th EDA (Equipment Data Acquisition) Seminar will be held on January 15th, 2020. It will be co-hosted with Linkgenesis, the regional distributor of CIMPortal Plus, the EDA suite from Cimetrix.

As EDA has expanded its footprint as the preferred industry standard among leading IDMs in the world of big data, AI, Machine Learning, and Industry 4.0, equipment makers face the challenges of delivering the new requirements of EDA without fully understanding its fundamental objectives, technologies, and benefits.

This seminar is designed with highly practical sessions where speakers will share their personal experiences and insights as developers to help software engineers at the equipment suppliers understand the most efficient ways to implement robust EDA interrfaces.

For registration and questions, please email Ian Ryu (ian.ryu@cimetrix.com).

Topics include the following:

1. Global and domestic EDA trends, including Freeze III, that will introduce major performance improvements.
2. EDA spec review – A summary of key contents from the newest and most demanding EDA specifications that a developer must know.
3. EDA modeling methodology and important lessons learning that Cimetrix engineers have gained while supporting many new EDA customers.
4. Testing methodology used during development and needed for EDA acceptance to ensure that standards compliance and interface performance expectations are met.
5. Other general topics
   a-Software roadmap for equipment makers
   b-Smart factory

We look forward to seeing you at the seminar!

씨메트릭스 코리아는 파트너사인 링크제니시스와 공동으로 제5회 EDA 세미나를 2020년 1월 15일에 개최하게 되었음을 기쁘게 생각합니다. 최근 몇년 간 EDA가 국내뿐 아니라 해외 반도체 제조사에서 빅데이터, AI, 인더스트리 4.0에 부응하기 위해 업계 표준으로 자리를 잡아감에 따라, 여러 장비회사들은, 복잡한 EDA 요구사항을 충분히 이해하지 못한 상황에서 관련된 요구사항을 개발해야하는 도전에 처해 있는 상황입니다.

한국에서 개최되는 금번 세미나는 실용적인 방법론을 최대한 강조한 세션들로 구성되어, 발표자들이 지난 수년 동안 쌓은 개발자로서의 경험과 통찰력을 최대한 공유함으로 참가한 개발자분들이 각자의 회사로 돌아가 EDA 인터페이스를 개발할 때, 최선의 개발 및 디자인 선택을 할 수 있도록 하였습니다.

참석하시는 분들에게 실전에 도움이 되는 유익한 시간이 되시리라 생각됩니다.

세미나 등록이나 기타 질문은 유종하 팀장 (ian.ryu@cimetrix.com)에게 연락 주시기 바랍니다.

세션은 아래와 같이 진행됩니다.

1. EDA의 국내외 동향(FREEZE III 포함) – EDA 관련 업계 현황과 큰 성능개선을 기대하는 Freeze III 소개
2. EDA Spec Review : 개발자로서 알아야 할 새롭고 복잡한 EDA  스펙의 키포인트 정리
3. EDA 모델링 개발 지원 경험 공유 – EDA를 신규 개발하는 여러 회사를 지원하며 축적된 경험 공유 및 방향성 제시
4. 개발 및 납품 시 테스트 방법론 – 개발과 검수 효율성을 향상
5. 일반 주제
1. 장비회사에서 가져야 할 소프트웨어 로드맵
2. 스마트팩토리 솔루션

감사합니다.

A SECS GEM driver can be looked at from a factory or equipment supplier perspective. I will discuss both of them in that order.

Factory Perspective

A little background:

From a factory perspective, a SECS GEM driver is the host software that talks to an equipment’s GEM interface. It allows the factory to take advantage of the features implemented in each equipment’s GEM interface. However, what the factory can do with an equipment’s GEM interface is also limited by what the equipment supplier has included in that interface. The GEM standard is very flexible and scalable, which accounts for the widespread and growing adoption of GEM technology—it can be adapted to any manufacturing equipment and market segment.

It is possible to implement features in a GEM interface. But this also means that just having a GEM interface on the equipment does not ensure that it has been correctly designed to meet the factory’s expectations. An equipment supplier’s poor implementation of GEM can frustrate a factory’s plans for Smart Manufacturing by not providing features that the factory expects that could have been implemented. The tendency of most equipment suppliers is to implement the absolute minimum functionality in a GEM interface to save money. Therefore, it is the responsibility of the factory during equipment acceptance to evaluate the GEM interface to make sure that it is robust and has the full set of required features. The factory must have a clear vision of its needs both initially and later as its Smart Manufacturing goals are realized. It is not unusual for a factory to request an upgrade to an equipment’s GEM interface with more features, but these modifications usually come at a cost.

Although a factory’s SECS GEM driver must be adaptable to different suppliers’ GEM implementations, it only needs to support the specific features that the factory uses. For example, if the factory is only concerned about alarm and event report notification, then it does not need to support the messages for recipe management, remote control or trace data collection. As such, the investment in a SECS GEM driver is proportional to the number of GRM features that are utilized. However, the SECS GEM driver should also support variations in alarm and collection event implementations, because each equipment type will support a unique set of alarms and a unique set of collection events with unique data variable for event reports. Moreover, from equipment type to equipment type, the same collection ID might have different meanings. The SECS GEM driver therefore needs an ability to adapt by having a method to characterize the GEM implementation (such as a list of available collection events) and the ability to map a general capability to the actual implementation (such as “material arrived” = collection event ID 5).

So why would a factory want to use SECS GEM technology?

In order to reach the goals of Industry 4.0 and Smart Manufacturing, factories must be able to monitor and control manufacturing equipment remotely. Therefore the equipment must have a software interface to provide this functionality and the factory must be able to access and use this interface.

Factories could let the equipment suppliers choose their own implementation technologies for this kind of capability, but as a result, different suppliers might take a different approach for every equipment type. This would be tremendously expensive and resource intensive. It is far better to standardize on one or two technologies, and ideally, one that is proven to work and known to have all of the necessary features. This allows the factory to achieve its goals with minimum investment, focusing instead on using the equipment interface in creative ways to improve manufacturing.

SECS GEM is the most proven technology already widely used across the globe and supported by the most sophisticated and automated industry in the world; semiconductor manufacturing. It is also widely adopted several other industries, making it a safe choice. The range of production applications supported by SECS GEM data collection include productivity monitoring, statistical and feedback/feedforward process control, recipe selection and execution tracking, fault detection and classification, predictive maintenance, reliability tracking, and many more. By contrast, alternatives to SECS GEM have so far been demonstrated to be incomplete or immature solutions. 

What specifically can you do with the SECS GEM technology?

1. Collection Events: Be notified when things happen at the equipment, such as when processing or inspection begins and completes, or when a particular step in a recipe is reached.
2. Collection Event Reports: Collect data with collection events. The host chooses what data it wants to receive. For example, track the ID of material arriving and departing from the equipment, or components placed on a board.
3. Alarms: Be notified when bad or dangerous things are detected, receive a text description of the alarm condition, and when the issue is cleared.
4. Trace Data Collection: Tell the equipment to report status information (software and/or hardware data) at a specific interval. For example, track digital and/or analog sensors during processing at 10 Hz frequency.
5. Recipes: Upload, download, delete and select recipes as desired, whether in ASCII or binary formats. Make sure that the right recipe is run at the right time to eliminate misprocessing and minimize scrap. Track when someone changes a recipe.
6. Remote Commands: Control the equipment, such as when to start, stop, pause, resume and abort. Custom commands, such as calibrate, skip or anything else can be supported.
7. Equipment Constants: Configure and track the equipment configuration settings remotely.
8. Terminal Services: Interact with the equipment operator remotely or provide instructions for the operator.
9. Extensions: There are numerous extensions to GEM that can be supported but are not yet form requirements. For example, implement wafer or strip maps from E142 to provide and report details about material in XML format.

Equipment Supplier Perspective

From an equipment supplier’s perspective, a SECS GEM driver is the software used to implement GEM technology on the equipment. In other words, the software to create a GEM interface. The equipment-side software requirements are inherently more complex that the host SECS GEM driver. This is because the equipment-side features are precisely defined by the GEM standard and should be implemented to the fullest extent possible. By contrast, the host can really do whatever it wants, so a limited implementation may be sufficient. In an ideal situation, the equipment supplier will implement just enough features in its GEM interface to satisfy all of its customers and therefore ship an identical GEM interface to all its customers. It is up to the equipment supplier to decide what GEM features to implement and how to adapt them for a particular type of equipment, but the factory should provide clear expectations about its planned use of the interface. It is also the factory’s responsibility to qualify the GEM interface during equipment acceptance. Note that it is not uncommon for factories to withhold partial equipment payment until the GEM interface has also passed its own acceptance.

Some equipment suppliers include the GEM driver as a standard feature on all equipment. This is ideal because it makes the GEM interface much easier to support and distribute. Some equipment suppliers only install GEM when it is specifically purchased. This often results in installation problems because the field technicians may or may not be knowledgeable enough or specifically trained to do this correctly. Other equipment suppliers include the GEM driver on all equipment, but only enable it when the feature has been purchased. This is better than attempting GEM interface installation after equipment delivery because the GEM interface can often be enabled with a simple equipment configuration setting.

Here are some key reasons for implementing a SECS GEM driver:

1. “One ring to rule them all”

By implementing a GEM interface, an equipment supplier can avoid having to implement multiple interfaces. Because GEM is the most feature complete option, the it should be implemented first and Thoroughly integrated with the equipment control and user interface software. If other protocols must be supported, they can usually be mapped onto the GEM capabilities or a separate external system because they only include a subset of GEM functionality.

2. Equipment Supplier Application Software

If the GEM implementation includes support for multiple host connections, then the GEM interface can be used by the equipment supplier itself for many applications. For example, an equipment supplier can develop a software package that monitors and controls their specific equipment at a factory. This can run simultaneously and independently while the factory GEM host software is connected. Many factories are willing to buy applications from the equipment supplier that enhance the productivity of the equipment they have purchased. As an example, equipment suppliers are better equipped to develop predictive maintenance applications that determine when parts are approaching failure and need replacement. These applications can save the factory time and money by avoiding unscheduled downtime. Other applications can also be developed by equipment suppliers to analyze and optimize equipment execution.

3. Competitive Advantage

A well implemented GEM interface can differentiate a supplier’s equipment from that of its competitors. Factories are beginning to recognize the value in controlling and monitoring equipment remotely, and know that a poor GEM interface contributes nothing to a factory’s Smart Manufacturing initiatives. A GEM interface that goes the extra mile to be truly useful empowers the factory to excel at Smart Manufacturing and to be far more productive. Selling equipment in today’s market without a GEM interface is like selling a television without a remote. On the other hand, providing a fully featured GEM interface is like selling a smart television.

Final Words

Experts on GEM technology are available all over world. Because GEM is a mature industry standard and well defined, it can be implemented by anyone in a range of different programming languages and operating systems. however, to save time I recommend using a commercially available product rather than developing the complete GEM interface from scratch. This can save massive amounts of time and effort, and ensures the quality of the resulting implementation.

To speak with a Cimetrix GEM expert, or to find out more about our GEM software products, you can schedule a meeting by clicking the link below.

SEMICON Japan 2019 is coming soon and we will be there! You can read about it now in Japanese or below in English.

Cimetrixは本年最後の業界エキジビションである、セミコンジャパン2019に出展致します。

今回Cimetrixとして初めての単独ブースを、東京ビックサイトで開催されるセミコンジャパン2019で出展します。期間は12月11日(水)~12月13日(金)です。
パートナーのブース(ローツェ株式会社様 #8419、および株式会社明電舎様＃7714)、またはCimetrixブース(#2467)に是非お立ち寄りください。

日本は世界半導体製造産業界に生産設備の3分の1、材料の半分以上を供給しています。ITを利用した高度な生産効率の改善を実現するためのスマートマニュファクチャリングの推進にあたり、革新的なソリューションとテクノロジーをセミコンジャパンをはじめとする展示会で積極的に紹介しています。

弊社ブースでは今回GEM装置接続・制御ソフトウェアソリューション、EDA/Interface A組み込み開発ソリューション、及び最新製品であるGEM/GEM300スタンダードコンプライアンステスターのEquipmentTestをご紹介します。お客様はEquipmentTestを使用することで、工場側通信システムに接続するための装置通信機能を迅速に検証できます。
本ツールはベーシックバージョンとプロフェッショナルバージョンが準備されており、GEM、PCBECI、及びSEMI SMT-ELSの完全な標準コンプライアンステストを使用可能です。

最新製品としてもうひとつ、Sapienceを展示します。
Sapienceはスマートマニュファクチャリングを実現するための、装置データハンドリングプラットフォームです。イベント駆動型フレームワークを採用しており、さまざまな装置設備と工場をシームレスに接続可能です。
工場のITシステムが設備に直接アクセス可能とすることで工場主体の装置通信、データ収集、プロセス制御を実現し、インダストリー4.0、ビッグデータ、スマートマニュファクチャリングの基盤を確立します。

また弊社は12月11日(水)午後3時10分から会議棟608号室、TechSTAGE SMART Manufacturingフォーラムにて講演を行います。今年のテーマは「組み立てラインにおけるスマート化」です。この講演では、弊社のシステム構築のエキスパートコンサルタントであるアラン・ウェーバーが、「半導体スマートマニュファクチャリング:後工程ファクトリーのスマートマニュファクチャリング実現の要件、スタンダード、ソリューション」というタイトルのプレゼンテーションを行います。

展示会期間中に、是非、弊社ブース#2467にお立ち寄りください。
生産設備のスマート化、スマートファクトリーソフトウェアの専門家がお待ちしています。
下のボタンをクリックして事前にミーティングを予約することも可能です。
お客様のご来訪をお待ち申し上げております。

Cimetrix is headed to Tokyo for SEMICON Japan 2019 – our last show of the year!

We are travelling to Tokyo, Japan next week to exhibit in our own booth at SEMICON Japan for the first time! This year’s show is once again located at Tokyo Big Sight from Wednesday, December 11 – Friday, December 13. Whether it’s at our partner booth (Rorze Corporation #8419 and Meiden #7714) or at the Cimetrix booth (#2467), we hope to see you there!

Japan supplies one third of the equipment and more than half of all materials to the global semiconductor manufacturing industry. As the world gets smarter, innovative solutions and technologies continue to be introduced at big shows like this.

Cimetrix will be showing all of our GEM equipment connectivity and control software solutions, as well as our EDA/Interface A products. We will also be introducing Japan to some of our newest products: Cimetrix EquipmentTest. This flexible software tool allows you to quickly validate an equipment’s ability to connect to a factory control system. It can be purchased in both the Basic and Pro versions, and supports full standards compliance tests for GEM, PCBECI and SEMI SMT-ELS out of the box.

Cimetrix Sapience will also be on display at our booth. Sapience is the Smart Factory Platform that seamlessly connects varying factory equipment within a single event-driven framework. The Sapience platform allows factory IT systems direct access to factory equipment, and the resulting equipment communication, data collection and process control establishes the foundation for Industry 4.0, Big Data and Smart Factory initiatives.

We are also privileged to have been invited to speak at the Smart Manufacturing Forum on Wednesday (Dec 11) afternoon at 3:10 pm on the TechSTAGE in Room 608 of the conference Tower. This year’s theme is “Realizing the SMART Assembly Line.” In this context, Alan Weber will deliver a presentation entitled “Semiconductor Smart Manufacturing: Requirements, Standards, and Solutions for the Back End.”

We encourage you to stop by booth #2467 and speak with an expert for your Smart Equipment and Smart Factory software needs! You can also book a meeting with us in advance by clicking the button below. We hope to see you soon.

The Cimetrix CIMPortal^TM Plus software product allows users to achieve compliance with the SEMI Interface A standards. This includes E120, E125, E132, E134 and E164. A key element in enabling the data collection provided by Interface A is the equipment model, which has three main purposes:

1. It defines the structure and relationships of the components that make up equipment (E120)
2. It defines the data (parameters, events and exceptions) that are available to be used in data collection (E125)
3. It defines the supporting structures (state machines, parameter type definitions, logical elements, etc.) for creating objects throughout the life of the running equipment (E125)

Part of the CIMPortal Plus Software Development Kit (SDK) is an application called Equipment Model Developer (EMDeveloper for short) that uses a simple drag and drop interface to allow CIMPortal Plus users to create a fully EDA-compliant equipment model. This includes making the model compliant with the E164 (Specification for EDA Common Metadata) standard which incorporates best practices from many production EDA implementations by defining common structures and other important conventions for the equipment metadata.

While EMDeveloper makes it simple to create, validate and deploy a fully compliant equipment model, there are times when equipment manufacturers want to provide a more flexible way of creating the equipment model. For example, an equipment manufacturer may offer multiple configurations of a unit of equipment with different arrangements of load ports and/or process module combinations. It is possible for the equipment supplier to save multiple equipment models that are shipped with each equipment, but this opens the door for possible human error in deploying an incorrect model file. It is also possible to create a “master model” that has all possible components defined. When the model is deployed, the equipment developer can use DisableModelNode functionality to disable the components that are not present. However, this approach may also result in errors, and is in the “gray” area of the standards (i.e., it is possible, but not encouraged).

Wouldn’t it be convenient if there was a way to create a model that exactly matched the equipment configuration?

We wouldn’t have a blog post if we didn’t already a positive answer to this question! EMDeveloper uses an API provided by the CIMPortal Plus CxModelLibrary. It does not use any sleight of hand or backdoors to create the equipment model. If a CIMPortal Plus user had the desire to do it, they could recreate EMDeveloper on their own. The API provided by CxModelLibrary allows users to programmatically create an EDA-compliant equipment model that exactly matches the desired equipment configuration.

When using programmatic model building, Cimetrix recommends first becoming familiar with the available API and determining the model building approach that works best for your equipment. The Solutions Engineering team at Cimetrix provides a sample application (including source code) that shows how to programmatically build an equipment model. This sample builds an E164-compliant model. In other words, all the expected parameters, events and exceptions and associated structures required by the standards are included as part of the resulting model.

The EDA standards – and specifically E164 – define the types of data that are required for various components in the equipment. For example, each substrate location in the model is required to implement a SubstrateLocation state model. Moreover, this state model must appear within the equipment node in the model hierarchy that matches the physical structure of the equipment. This sample illustrates best practices in constructing model objects that can be reused based on the type of component. Programmatic model building may take a little more investment up front, but in the end, it can pay big dividends to those equipment providers that may need to change their equipment model on the fly depending on its configuration.

Once a model has been programmatically created/modified, Cimetrix also provides an API for validating the model, deploying the model to be used by an EDA client and creating an Access Control List (ACL) entry to allow a client to securely connect to the interface and gather data.

There is also a provision in the standard for addressing the concern that if the model is updated dynamically, an EDA client may have data collection plans (DCPs) that become out of sync with the modified model. In this case, the client is notified of model changes, and can also be designed to dynamically update the data collection plans based on the changes.

The Cimetrix CIMControlFramework (CCF) product makes use of this programmatic model building functionality. CCF dynamic model building is described in a blog post that you can find here.

To learn more about the EDA/Interface A standards, CIMPortal Plus or programmatic model building, click below and a Cimetrix expert will contact you. 

The SEMI North American standards meetings for the Information and Control Committee were held recently and the following is a summary of some of the highlights and action items. 

In the GEM 300 task force, a revision to GEM officially removed E139 as a recipe management option. A planned revision to GEM should be much more exciting and progressive, but this work cannot begin until E30 is published with the current changes. In the meantime, future near-term plans include defining new SECS-II messages to improve host access to data collection setup and some terminology clarification. Brian Rubow from Cimetrix continues to co-lead this task force with Chris Maloney of Intel.

In the DDA (Diagnostics Data Acquisition) task force, which Brian Rubow from Cimetrix continues to co-lead, the standard that establishes gRPC and Protocol Buffers for EDA freeze 3 was approved. However proposed changes to the other core standards E125, E132 and E134 all failed, as well as the gRPC adoption for E132. The failures were expected. Additionally the North America DDA task force leaders continue to actively collaborate with the co-leaders of the DDA task force in South Korea. It is a great example of competitors working together at SEMI to create common solutions that satisfy everyone’s requirements.

Tami Tracy, a Cimetrix Solutions Engineering Manager, was officially voted in as a GUI task force co-leader for 2020, co-leading with Frank Summers. Congratulations and thanks to Tami for volunteering for this position. This will accelerate the task force's plans to modernize the SEMI E95 standard.

The Computer and Device Security (CDS) task force announced a vastly improved collaboration with its sister organization in Taiwan which has officially agreed to "divide and conquer" rather than attempting to address the entire scope of this domain with a single standard. A few months ago, the two groups seemed to be at odds with each other...The Taiwan task force proposed to include all factory and equipment security issues in one effort, while the North American task force wanted to focus initially on the equipment issues. The Taiwan, Japan and North America Task Force Leadership have now agreed to convert the Specification for Malware Free Equipment Integration (SNARF) 6506 into an overarching standard. The CDS task force is moving forward on SNARF 6566, and received authorization for a ballot on this proposed new standard for Cycle 2-2020.

The Advanced Factory Factory Integration (ABFI) task force, headed by Brian Rubow (Director of Solutions Engineering, Cimetrix) and Dave Huntley (PDF Solutions), held its first task force meeting. One order of business is to update E142 substrate mapping. The task force intends to map equipment features to SEMI standards including GEM and GEM 300. This effort could facilitate adoption of the GEM standard on equipment that previously had little interface standardization. It should also encourage further advance the goals of Smart Manufacturing and Industry 4.0 in related industries, encouraging more factories and equipment to adopt the standards that have been so successfully applied in semiconductor manufacturing for decades.

To find out more, you can speak with an industry standards expert today by clicking the link below.

In the early 1990’s I worked with companies like Motorola, Wacker Siltronics, and AT&T to characterize the SEMI Equipment Communication Standards (SECS) interface on the equipment. It was early in the process of connecting process and metrology equipment to a factory control system (Manufacturing Execution System – MES), in the days before the leading chip makers at that time got together to define the Generic Equipment Model (GEM), which was eventually balloted as SEMI E30.

It was a fun and exciting time as process owners began to see the power and benefit of having an automated interface to the equipment. The first project I worked on was collecting critical dimension (CD) data from a microscope following a lithography process step. Previously the operators would manually enter 6 measurement data points to 8-digit precision. This was a very error-prone process, and each time a mistake was made, lots were put on hold until the problem was diagnosed. This affected not only the throughput of the lithography area, but also the overall fab, since the litho tools are invariably the bottleneck. The automated interface eliminated this problem because process engineers knew that any lot holds were due to real process errors rather than operator input errors.

Moving the automated interface to the process equipment was a little more difficult. An automated interface on a metrology tool cannot cause misprocessing, but an automated interface on a process tool was a little riskier. We decided that the first step would be to simply verify that the correct recipe was selected, and not allow processing to proceed until it was reviewed by the process Engineer assigned to that equipment. Within a few minutes of going live with the first automated interface for a process equipment, a mismatch was detected between the operator-selected recipe and the recipe specified in the MES. A quick check by the process engineer verified that the technician had indeed selected the wrong recipe—this simple check alone saved misprocessing the entire carrier of material.

From these humble beginnings, full factory automation in front end 300mm fabs was adopted quickly and revolutionized semiconductor manufacturing. The level of automation in other areas of the semiconductor and electronics assembly industries is now increasing dramatically, motivated by the prospect of improved factory throughput and higher yields. Moreover, the experience gained through implementation of automated interfaces using SEMI communication standards will be a great benefit to semiconductor backend and electronics assembly markets. Some of the standards used in 300mm automation have already been modified for this purpose, and new standards are in work to better serve these industries.

In September 2019, SEMI published the PCBECI (Printed Circuit Board Equipment Communications Interface) standard, officially designated SEMI A3. This standard is a simplification of the reliable and much-used GEM equipment communication standard.

Early in 2019 the SMT-ELS (Surface Mount Technology Equipment Link Standard) suite, designated SEMI A1, A1.1, and A2, was also published. These standards address the need for machine-to-machine (M2M) communications to support flow manufacturing processes. The adoption process for these new standards has just begun, but like the early adoption of the SECS and GEM standards, it is exciting times and good things are happening. 

Visit us as Productronica (Hall A3 Booth 421) or SEMICON Europa (Hall B1 Booth 525) to hear more about these new standards and the products Cimetrix has developed to support their implementation and validation in equipment and factories. Or you can get in touch with a standards expert any time by clicking the link below.