Posted on Thu, Jun 24, 2010
by Dave Faulkner,
EVP, Sales & Marketing
Engineers love data. Business people love information. But it all starts with high-quality, real-time data. The possibilities are endless with good data.
As an equipment supplier, history probably has you living with a tool architecture from the early 300mm days. The focus was on implementing AMHS systems and meeting the GEM300 standards. A data driven architecture wasn't on the radar screen. And it wasn't a business priority. Times have changed. Fabs started asking for more data by creating the SEMI Interface A standards - and equipment suppliers are learning they can produce more productive equipment by leveraging the right data.
Interface A was an interesting concept when it started in the early 2000s. Discoverable data available to the fabs in real time would seem to be the answer to many problems. But the adoption has been less than stellar - even with strong endorsement and technical support by ISMI. Lack of fab side applications plumbed to use the Interface A data and "ownership" issues of the data haven't helped. These are real business problems that must be solved and will be solved with the next wave of fab purchases.
But what have we learned as equipment suppliers and software providers? Tool data models are helpful. Self description is great. We can create high performance data gathering applications that integrate with existing tool control architectures to make data available and controllable by the equipment supplier. Look at the performance of CIMPortal, our comprehensive equipment data acquisition (EDA) solution. We also learned that given the opportunity to "start over", we can create new tool control architectures that are data driven and prepared for the future. Look at CIMControlFramework. So the data is available - or you can make it available with an existing or new tool control architecture.
Let's put this data to work. Either to benefit you as the tool supplier or to help your customer. How is your tool accepted at the fabs? Do you have contingencies on your customer's payments? Does tool uptime have an impact on the tool price? Are your warranty costs too high? You get the point. With high-quality, real-time data at our fingertips, we can solve some of these business issues. We are at the beginning of a phase where the tool supplier makes use of this data and it directly impacts business results. Tool side fault detection, preventative maintenance, whatever is needed. The important point is we are finally starting from a strong foundation with the right data at the right time - and it can lead to increased margins or higher levels of customer satisfaction. Bring us your business problem and let's build something together to put this data to good use. Let's do it now!
You might also be interested in:
Posted on Tue, Jun 08, 2010
by Brian Rubow,
Product Manager
I have been a Scoutmaster for the Boy Scouts of America for about 5 years now. Our troop goes camping several times a year. Utah offers a lot of beautiful and interesting camping areas. The variety is remarkable. In our troop we spent a lot of time teaching and preparing the boys to not only have fun, but also be safe and wise in their fun. Some planning ahead, training and common sense can make a huge difference. Nearly every week, I have our Senior Patrol Leader help all of the scouts in our troop recite a number of memorized phrases including the Scout Oath, Law, Slogan, Motto and sometimes even the Outdoor Code. The Scout Motto is the famous one known to almost everyone in the world; "Be Prepared". Reciting it every week helps our minds to remember to focus on being prepared for whatever may come. We prepare the boys to handle emergency situations such as medical and weather related emergencies. "Be Prepared" applies not only to scouting activities like camping, canoeing and hiking, but also to school, our careers and everything we do.
At Cimetrix we also like to "Be Prepared". In particular, at the time we designed our EDA (Interface A) products, CIMPortal and EDAConnect we recognized a need to support multiple versions of the standard. Since 2006, there has been only one allowed version of the EDA standards. This is the ISMI Freeze Version which specifies the 1105 version of the SEMI® standards. At Cimetrix we knew that at some point in the future the 1105 ISMI Freeze Version would not be the only version implemented. As co-chair of the DDA Task Force responsible for the development of the SEMI EDA standards, I can personally attest that the standards have continued to change, mature and improve. At Cimetrix, we predicted from the start that at some point in the future, factories would want these new features in the standards and that ISMI would announce another EDA Freeze Version.
Due to the nature of the underlying SOAP/XML technology, the client and equipment are required to use the same version of the SEMI standards. With one and only one ISMI Freeze Version, this is easy. Everyone's implementation works with everyone else's implementation. With more than one ISMI Freeze Version, it is more complicated. Each equipment supplier has to support each ISMI Freeze Version to communicate with the different client software at different factories or even in the same factory. Each factory has to support each ISMI Freeze Version to communicate with the different equipment implementing different versions.
ISMI is poised to announce another EDA Freeze Version soon. Certainly the factories using the EDA standards will expect equipment suppliers to adopt the new version as soon as possible. And certainly factory data collection applications will want to adopt the new version and take advantage of the new features.
To "Be Prepared" for the future, Cimetrix originally designed both EDA products, CIMPortal and EDAConnect, for the future. Each product is designed with an abstraction layer to be able to support multiple EDA versions at the same time. This makes it possible for Cimetrix to adopt the new EDA versions without rearchitecting the products. In turn, this passes on tremendous value to our customers who also will not have to rearchitect their solutions. In fact, Cimetrix customer should be able to upgrade to new Freeze Versions with relative ease. It is nice to "Be Prepared".
Schedule a meeting at SEMICON® West 2010 to discuss your Interface A needs further!
Or visit us at Booth #2331, South Hall.
You might also be interested:
Posted on Thu, May 27, 2010
by Brent Forsgren,
Director of OEM Solutions
Fabs are like people, each one has it own personality traits. Fortunately, and arguably unfortunately, unlike people, most fabs have a handbook for their “personalities” in the form of specifications. I have found it interesting, that like people, fab “personalities” have common and unique features. Here are a few of examples:
- There are some fabs that I would classify as the “Clean Freak.” Compliance to GEM and GEM 300 standards is important but more important to them is preventing cross contamination between FOUPs, and from wafer to wafer – “Who left this loadport door open? Don’t you know you can spread particles by doing that??”
- Then there are other fabs that I would classify as the “Punctilious.” Again, compliance to the GEM and GEM300 standards is required but more important to them is knowing exactly when you are going to be done, when you are ready for more, are you done yet, how much longer are you going to be, are you done yet?
- Then there are other fabs that are “Methodical-ious” (if I can make that a word). Everything must happen in a very specific order. 1) Don’t allow jobs to exist without material at the tool first; 2) Download the recipe before every job that is created; 3) Create the job now. 4) If the FOUP is removed before the job starts, refer to rule 1.
- And let’s admit it, all fabs are “Control Freaks,” if they weren’t we wouldn’t be in business. They control when jobs are run, how jobs are run, and what a job does.
Hmmmm……that makes me wonder, if fabs are like people, does that make companies like Cimetrix psychiatrists?
You might also be interested in:
Posted on Thu, Apr 01, 2010
by Bob Reback,
President and CEO
I always enjoy meeting with customers. I may be a little “old school,” but the personal touch of sitting across the table from someone, having a cup of coffee and learning firsthand what they think of our products, our people and our services is always educational, and even more so when the news is not good, as that gives us the opportunity to learn and improve going forward. Of course, the non-verbal communication is often times more important than the words, and you just can’t get that over the phone.
Due to the downturn in economic conditions during late 2008 and early 2009, we limited all company paid travel. As president, I also set the example to use the telephone and web conferences for most customer interactions. As business conditions began to improve in late summer of 2009, we began to relax our travel constraints. This led me to take a business trip to Europe to meet with some of our semiconductor customers as well as a few of our new PV customers.
Being on the road visiting customers usually involves a very full schedule, and Cimetrix business trips are even more so. This business trip started off meeting with customers in The Netherlands and then we drove across Germany meeting with customers in a number of cities as we made our way to our final destination in the Munich area. As we drove across Germany and stopped in a number of cities and small towns, I was surprised to see quite a few modern, high tech windmills, but I was shocked at the solar panels. We saw solar panels on the roofs of commercial buildings, residential building, farms and just about any type of structure with a roof. We saw solar panels in cities, towns and the countryside as we drove by on the Autobahn.
The German government has been the world leader in promoting renewable energy. The German government implemented a program of “feed in” tariffs that provide subsidies for entities (people, businesses, etc.) to install solar panels. As it was explained to me, it is typical in Germany to purchase electricity at a rate of say $0.08 to $0.10 per kilowatt hour. The government feed-in tariff means that if someone installs solar panels on their roof, the German government will guarantee that it will purchase all of the electricity from your solar panels for the next 20 years at the price of $0.45 per kilowatt hour. (Note that the feed-in tariffs decline every year). Since you have a guaranteed contract to sell this electricity to the government, people are able to go to a bank and borrow the funds to cover the upfront costs of installing the solar panels. Then the profit obtained on a monthly basis is sufficient to pay back the loan and interest charges. After about 10 years, the loan is paid off and then the person with the solar panels can enjoy the operating profits for the remaining years on the original 20 year contract. It was fascinating to see firsthand the results of this program, as well as have discussions with many of the German people. Not only did we discuss with many of the engineers that are our customers, but we had discussions with the average citizens in various restaurants and hotels. Everyone knew the term “PV” and there was certainly an air of excitement about leading the world in renewable energy.
You might ask, “How does this affect Cimetrix?” Well the theory is that government feed-in tariffs will stimulate demand, which in turn will stimulate production of more solar panels, which will then lead to improved efficiencies in both the technology used in solar panels as well as the economies of scale, which will ultimately lead to better price/performance solar panels that are cost effective on their own merits without government subsidies. Since solar panels are based on silicon or thin film substrates and have a similar manufacturing process to computer chips, there is a need to continually improve the manufacturing process to make better solar cells and lower the manufacturing costs. That is where factory connectivity and advanced software systems similar to those used in semiconductor manufacturing come into play. Many of the German PV manufacturers have adopted the “PV2” software for connecting manufacturing equipment with factory software. Cimetrix has enhanced its product offerings to meet these needs and hopes the industry is successful in promoting widespread usage of these PV software standards. If this happens, this should significantly increase the available market for Cimetrix products and services.
You might also be interested in:
Posted on Thu, Mar 18, 2010
by Doug Rust,
Director, Product Engineering & Customer Support
The time shift for daylight savings this week is going to cause me some grief for some time. Most countries in Europe will not adjust until March 28. Many countries in Asia (India, Singapore, Taiwan, Malaysia and Japan for example) are not adjusting for daylight savings at all in 2010. Since our customers are all over the world, I’m going to have a tough time keeping in sync. It’s inevitable that I’ll miss some important event this month. So, I thought it would be very àpropos to submit a blog about Time Synchronization.
SEMI® standard E148 defines software standards for the equipment communication interface to enable the equipment control computers to automatically synchronize their clocks from a standard time base. Although this standard was just published a couple years ago, it is not new technology. Computer systems have been using internet technology to synchronize their clocks with a common time base for over 20 years now. The Network Time Protocol (NTP – a.k.a RFC1305) is the internet standard for time synchronization that is designed to enable any computer to synchronize with a reference clock (most commonly the atomic clock in Colorado) through various time servers available on the internet. SEMI E148 specifies the NTP standard as the mechanism for synchronizing the equipment control computer with the factory computer systems (as well as some other requirements).
This is becoming a critical capability as factories begin to adopt other information technology that enables them to collect thousands of precise data points from each run on each tool. Making effective use of this data requires that the time-base for data source ‘A’ is the same as the time base for other data sources so that the raw data can be assimilated and correlated to produce valuable manufacturing information. If there was some important “event” in manufacturing that we need to analyze the first thing we will do is to try to determine what else was happening at the time of that event. So the first question we ask is “when did that occur?” That’s where we can run into serious problems if there is no common time base.
Most modern operating systems have the NTP client software built-in. It’s possible to synchronize with reliable time servers on the internet and there are many affordable commercial time servers available. Even if users do not implement all of the E148 requirements, I suspect we are going to see more and more factory networks using NTP to synchronize the manufacturing equipment with factory hosts over the next year (if they haven’t already done it). For me, I guess I’m going to be out of sync at least until May 28.
You might also be interested in:
Posted on Thu, Mar 11, 2010
by DeAnn Rowan,
Marketing
As a blog reader, we would like to ask you a question:
So….What do you think?
We’ve been at this blogging thing for 6 months (almost to the day) now. We’ve seen a lot of interest as the traffic to our blog posts continues to rise at a rapid pace. The entire Cimetrix team has provided contributions and feels passionate about the information that we have been sharing with readers.
Some of our most popular posts to date – and ones you’ll want to check out if you haven’t already - include a narrative touting the benefits of software frameworks, a comparison of the data collection functions of SECS/GEM and Interface A, and the answer to the “He Said/ She Said” game between equipment and host.
What have you found to be the most valuable?
What topics would you like to see discussed more? Or less?
We want to be a resource of information for you regarding the SEMI connectivity standards and their implementation. As you read through our blog, please feel free to ask questions or provide insight on the topics being discussed. We welcome your comments!
In addition to this blog, we encourage you to interact with us, and others within the manufacturing community, via various social media networks:
Use these avenues as an alternative means to ask questions, provide feedback, and stay abreast of any industry or Cimetrix updates.
Thank you for your continued readership and we look forward to future discussions.
Connect with Us on LinkedIn:
Also check out the resources page of our website which offers several white papers, presentations, and articles for download on these topics!
Posted on Tue, Feb 09, 2010
by Matt Mayer,
Principal Software Engineer, Global Services
- Establishing Communication- A standardized communications mechanism ensures both equipment and host have agreed, and all requirements necessary for properly collaborating data (between tool and host) based on the SEMI® SECS messaging standards (E5) are compatible during the connected status and after connection could have been disrupted.
Spooling- Spooling is an essential part of keeping synchronization with the tool. Communications (connect status) can be disrupted. In the event of communication disruption, the tool can be configured to spool collection event (S6F11) messages after communications has been restored and the host requests the last know transactions for the lost time span.
Spooling can be configured to retain a SECS message pooled history of almost any stream and function (SEMI E5 standard). With this enriched functional capability, any condition of the tool can be relayed at anytime after communication has been re-established (e.g.: alarms, events, processing state changes, etc…).
With that said about spooling, the host is required to take special care of the data received and re-act to the latest available data (spooled messages) in the most appropriate manner. In many cases, this behavior of the host takes special care at documentation and tool manufacturer collaboration.
Alarm Handling- The alarm handling capability provides for host with notifications and management of alarm conditions occurring on the equipment. Typically an alarm is associated with abnormal conditions of the equipment.
With each alarm a correlating set/clear event notification will be issued to the host. As with each event definition, a report can be defined and linked in order to associate variable data specific to the alarm (see Event Handling).
Event Handling- Event handling provides a dynamic and flexible method for the tool manufacturer to customize the equipment to meet needs specified by the fabrication facilities with respect to data representation and presentation to the host. The event based approach to data collection provides automatic notification to the host and its activities which are useful in monitoring the equipment and in maintaining synchronization with the equipment.
Reports can be configured by the host application and attached to event report messages (S6F11). These reports are linked to the desired event and are typically associated with variable data relating to the event generated by the equipment.
Variable Handling- The variable handling capability provide both the tool and equipment the ability to share details. Variables are categorized in three groups.
Groups:
- Equipment Constants, provides the capability for the host to read and change the value of selected variables of type EC which allow the host to reconfigure the variety of equipment functionality.
- Status data, the values of a status variable will be current.
- Discrete data, the values of DVs are only guaranteed to be valid at the occurrence of a collection event.
Process State Model Handling- The processing state model is dependent on the equipment process and technology. However, there are expected common aspects to these models. Many of these equipments use the GEM proposed state model with some variations. An ERROR and MANUAL state can be utilized during initialization and when the state is idle.
Based on the SEMI E30 standard, the equipment must generate collection events for each processing state transition, as well as provide status variables (ProcessState, PreviousProcessState) which values represent the current processing state and the previous processing state. Other collection event reports can be defined and linked to event triggers.
Remote Command Handling- The capability which provides the host with control over the equipment and its operations. A remote command consists of parameter name/value pair with a particular host command (S2F41). The equipment manufacturer will provide unique names for any supported command parameters. The command parameters are defined by fabrication facilities and equipment manufacturers.
A typical set of remote commands are listed below. However, the list is not a constraint and any set of remote commands can be specified and used.
- PPSELECT
- START
- STOP
- PAUSE
- ABORT
Recipe Upload/Download Handling- Recipe handling provides the means for transferring process (recipe) information between the host and the equipment. The specifications for equipment processing (e.g. recipes) are managed through SECS messages (E5). Recipe uploading and downloading will be accomplished using several formats and combination thereof.
Formats:
- Unformatted recipe content
- Formatted recipe content
- Value based content transfer
- File based content transfer
In addition to the above mentioned considerations, Cimetrix's CIMConnect, an object-oriented software development kit for equipment suppliers to quickly develop a GEM interface, also allows for multi-host connections.
You might also be interested in:
Posted on Tue, Nov 10, 2009
by Vladimir Chumakov,
Software Engineer
HSMS or High-Speed SECS Message Services is a messaging protocol used in semiconductor and other industries as means for connecting to, controlling and gathering data from equipment inside the factory. HSMS provides means for independent manufacturers to produce implementations which can be connected and interoperate without requiring specific knowledge of one another.
HSMS was defined by SEMI in the mid 1990’s as an alternative to aging SECS-I protocol that uses much slower and otherwise more limited RS-232 hardware.
HSMS vs. SECS-I:
- Throughput – HSMS uses TCP/IP and Ethernet which allow speeds up to 1000Mb/s (and higher as technology advances) where SECS-I is limited to 9600b/s or even slower when length of connection between devices increases.
- Distance – lengths of RS-232 cables is usually limited to somewhere less than 1000 feet where Ethernet, with the use of additional devices such as network hubs, has no limits.
- Connectivity – RS-232 is a point-to-point connection where each device has to have an available hardware port. In the factory, a GEM Host has to connect hundreds of equipments and has to have a separate dedicated RS-232 port for each one. With HSMS, a computer with single network interface card can connect to hundreds of equipment.
HSMS is used in all modern semiconductor factories as means for the factory host system to connect to, monitor and control individual equipments.
You might also be interested in:
Posted on Tue, Nov 03, 2009
Industry organizations, such as SEMI and ISMI, have been touting the benefits of the Interface A, also known as EDA, standards for years. This year, SEMI approved an important revision to these standards to incorporate many of the lessons learned from early implementations. In addition, SEMATECH member companies (which make up 50 percent of the worldwide chip market) wanted ISMI to focus on a smaller number of projects with short-term benefits for 2009. Interface A (EDA) is on this short list.
Want to learn more?
Cimetrix is hosting a FREE webinar outlining the features and benefits of the Interface A standards. The material will be presented by Doug Rust, Director of Quality Customer Support and co-chair of the SEMI North America GEM300 Task Force.
FREE WEBINAR: Interface A Features & Benefits
Date: Thursday, November 12, 2009
Time: 8:00 am MST/ 7:00 am PST/ 10:00 am EST/ 3:00 pm GMT
Duration: 1 hour
Learn from Cimetrix's experienced engineering staff just what the
Interface A standards are and how you can benefit from better quality and higher quantity data.
- The key features & benefits of Interface A
- Data & reporting features available through Interface A
- The role of Interface A in manufacturing
DOWNLOAD THE RECORDED WEBINAR HERE.
You may also be interested in:
Posted on Tue, Oct 06, 2009
by Bill Grey,
Director of Research & Development
Engineers often ask, “What are the differences between Interface A and SECS/GEM for data collection.” This is a high-level comparison of Interface A and SECS/GEM/HSMS-SS data collection features. We are working on some tools to help demonstrate Interface A data collection. More on that later….
Clients
Interface A supports multiple clients where SECS/GEM is usually a single client.
Security
Interface A can be configured for SSL secured communications. Only clients with a valid certificate can use the interface and all data across the wire is encrypted.
HSMS is not secured. In HSMS, any host that has the device ID can connect and data across the wire is binary encoded, but not encrypted.
Additionally, Interface A client features are gated by privileges where GEM features are not privileged.
Equipment Model
Interface A E125 provides methods for its client to upload a description of the logical structure of the equipment which includes parameters, events, and exceptions assigned to modules, subsystems, and IO devices. In this manner, each parameter, event, and exception has the context of the owning component.
In GEM, similar information is found in a manual provided with the equipment. Unfortunately, in most equipment manuals, the relationship of which component on the equipment produces the parameter, event, or exception is not available. Context is missing.
Traces
Interface A traces have features that GEM traces do not. Interface A traces have start and stop triggers. These triggers may include one or more events and/or exceptions. The trace would begin collecting data when any of the start triggers occurs and stop collecting data when one of the stop triggers occurs. This is useful as a trace for a processing module may be defined to start when a processing started event occurs and to stop when a processing completed event occurs for that module. In this manner, the Interface A client defines the trace once and collects the data only when processing is active. Between the triggers, data is collected at the specified rate. The rate is specified with a floating point number designating the number of seconds between samples. The resolution is limited by the equipment.
In GEM, traces begin when defined through a SECS message and end when the specified number of samples is collected. To achieve the same effect as Interface A, a host would have to define event reports for the processing module processing started and processing completed events. When the processing started event is received, the host would have to define the trace by sending a SECS message. When the processing completed event is received, the host would have to terminate the trace with a SECS message. The host would have to do this every time, unlike Interface A. There is a delay between the processing started event and when the trace starts because of the SECS messaging that isn’t there with Interface A. GEM traces are limited to centisecond resolution by the E5 standard even if the equipment could support faster traces. Some older GEM implementations are limited second resolution.
Event Reports
Interface A event reports specify an event and an optional set of parameters to be collected when that event occurs. The Interface A client activates the event report to begin monitoring the event and deactivates the report to stop monitoring the event.
GEM event reports are a little different. A GEM host defines collections of parameters called reports. Then it links one or more reports to one or more events. The same report may be linked to multiple events if needed. Then the host enables the event to begin monitoring the event and disables the event to stop monitoring the event.
Alarm Reporting
Interface A exception reporting is very different than GEM Alarm reporting. Interface A exception reports are defined using a source ID, exception ID, and severity. Any of the fields may be empty or filled in. Source ID identifies which component provides the alarm, for example a processing module or load port. If source ID is the only non-empty field, then all exceptions for that component will be monitored and reported. Exception ID identifies a specific exception name, if this is the only non-empty field, then all exceptions matching this name regardless of source will be monitored and reported. If severity is the only non-empty field, then all exceptions matching this severity will be monitored and reported regardless of source ID or exception ID. If more than one of these fields is non-empty, then reporting will be determined by applying Boolean AND logic to the fields. In addition, exception reports in Interface A may contain parameter data; however, which parameters are supplied with each exception is specified by the equipment manufacturer and not selectable by the Interface A Client.
GEM alarm reporting has two forms. For notification of an alarm being set or cleared, the host may enable alarms and receive a SECS message containing no other data. In GEM, each alarm has one set and one clear event that may be used for event reports. Using these events, the host may be notified of alarm set and clear transitions with reports that contain data chosen by the host.
Reports
Neither Interface A nor GEM provide annotated reports.
Data Collection Impact
Interface A E134 defines a mechanism for the equipment to limit the impact of client defined data collection on material processing. If data collection hinders processing, the equipment may issue a Performance Warning to all clients and deactivate their data collection. The equipment may resume data collection at a later time and issue a Performance Restored.
GEM defines no such throttling or notification mechanism.
You may also be interested in: