Industry News, Trends and Technology, and Standards Updates

In the EDA Best Practices blog series, we have discussed choosing a commercial software platform, using that package to differentiate your data collection capabilities and how to choose what types of data to publish. In this post we will review why you should choose to provide an E164-compliant equipment model.

What is E164?

Equipment Data Acquisition (EDA) - also referred to as Interface A - offers semiconductor manufacturers the ability to collect a significant amount of data that is crucial to the manufacturing process. This data is represented on the equipment as a model, which is communicated to EDA clients as metadata sets. The metadata, based upon the SEMI E125 Specification for Equipment Self-Description, includes the equipment components, events, and exceptions, along with all the available data parameters.

Since the advent of the SEMI EDA standards, developers and fabs have recognized that equipment models, and the resulting metadata sets, can vary greatly. It is possible to create vastly different models for similar pieces of equipment and have both models be compliant with the EDA standards. This makes it difficult for the factories to know where to find the data they are interested in from one type of equipment to another.

Recognizing this issue, the early adopters of the EDA standards launched an initiative in to make the transition to EDA easier and ensure consistency of equipment models and metadata from equipment to equipment. This effort resulted in the E164 EDA Common Metadata standard, approved in July 2012. Another part of this initiative was the development of the Metadata Conformance Analyzer (MCA), which is a utility that tests conformance to this standard. With this specification, equipment modeling is more clearly defined and provides more consistent models between equipment suppliers. This makes it easier for EDA/Interface A users to navigate models and find the data they need.

Power of E164

The E164 standard requires strict name enforcement for events called out in the GEM300 SEMI standards. It also requires that all state machines contain all of the transitions and in the right order as those called out in the GEM300 standards. This includes state machines in E90 for substrate locations and in E157 for process management. The states and transition names in these state machines must match the names specified in the GEM300 standards.

These requirements may seem unnecessarily strict, but implementing the common metadata standard results in:

• Consistent implementations of GEM300
• Commonality across equipment types
• Automation of many data collection processes
• Less work to interpret collected data
• Ability for true “plug and play” applications
• Major increases in application software engineering efficiency

Knowing that a model is E164 compliant allows EDA client applications to easily and programmatically define data collection plans knowing that the compliant models must provide all of the specified data with the specified names. For example, the following application is able to track carrier arrival and slotmap information as well as movement of material through a piece of equipment and process data for that equipment.

This application will work for any GEM300 equipment that is E164 compliant. The client application developer can confidently create data collection plans for these state machines, knowing that an E164-compliant model must provide the needed state machines and data with the proscribed names.

Decide to be E164 compliant

A number of leading semiconductor manufacturers around the globe have seen the power of requiring their equipment suppliers to provide EDA/E164 on their equipment, and now require it in their purchase specifications.

If you are a semiconductor manufacturer, you should seriously consider doing the same because it will greatly simplify data collection from the equipment (and most of your candidate suppliers probably have an implementation available or underway.

If you are an equipment supplier and your factory customers have not required that your EDA models be E164 compliant, you should still seriously consider providing this capability anyway as a way to differentiate your equipment. Moveover, E164-compliant models are fully compliant with all other EDA standards. Finally, it is much easier and more cost effective to create E164-compliant models from the outset than it is to create non-compliant models and then convert to E164 when the factory requires it.

Conclusion

The purpose of the E164 specification is to encourage companies developing EDA/Interface A connections to implement a more common representation of equipment metadata. By following the E164 standard, equipment suppliers and factories can establish greater consistency from equipment to equipment and from factory to factory. That consistency will make it easier and faster for equipment suppliers to provide a consistent EDA interface, and for factories to develop EDA client applications.

Cimetrix held its annual shareholder meeting this past Friday, August 16, 2019 at our headquarters in Salt Lake City, UT. It was nice to see many familiar faces as well as some new faces. There was just one proposal voted on at the meeting to re-elect all five Directors, which was approved by shareholders with over 99% of the votes cast in favor of the proposal. Bob Reback, our President and CEO, introduced each member of Board of Directors and provided a brief history of each board member’s tenure with Cimetrix and the specific expertise and value each of them bring to Cimetrix and our shareholders. We appreciate the wisdom, hard work and direction from our talented board members as well as their commitment to fairly represent the interests of shareholders. We are thankful to our shareholders for their continued support of Management and our Board of Directors.

After the formal shareholder meeting was adjourned, Dave Faulkner, Executive Vice President of Sales and Marketing, and Alan Weber, Vice President, New Product Innovations, presented an update on industry trends, our product portfolio and growth opportunities. Following their presentation, Bob Reback, provided an update on the State-of-the-Company, including the company’s increased CAGR of 28% compared to the 6% CAGR as a public company from 2002 through 2013. Cimetrix ended the 2018 fiscal year with profitable operations, no debt, and over $3M of cash.

We continue to be thankful for the support and enthusiasm demonstrated by our shareholders, the hard work of all our employees, and the guidance from our Board of Directors. Thank you for all your contributions to Cimetrix.

There are some of us in the software development community who recall when cloud computing was not much more than a marketing buzzword, mocked by many developers with first-hand experience at the pace of change in the internet age, but maybe not quite enough experience to know better. Today, cloud-enabled architectures are so commonplace that it’s the alternatives that must be defended in most quarters. Although not necessarily in manufacturing.

In parallel to cloud computing, Industry 4.0 and Smart Manufacturing are happening, and the effects are becoming more apparent and impossible to ignore. Fewer people are mocking I4.0 and Smart Manufacturing as buzzwords. More often, they are being better defined as a set of useful principles and applied to real-world problems with exciting results.The confluence of I4.0 and cloud computing is a rather rare intersecting set. For many manufacturers, it’s a bit much. Those of us working in this area understand the famous quote (mis)attributed to Mahatma Gandhi: “First they ignore you, then they mock you, then they fight you, then you win.” The fight is underway; the confluence of cloud computing and Smart Manufacturing are the focus of this writing.

During the Industry 3.0 changes, when computers were introduced in a significant wayts themselves all changed. Now that Industry 4.0 is upon us, it is the networking of these machines that is driving the change. The network effect is easy enough to understand, but the resulting change is bound to have ripple effects across the industry that will be hard to predict.

Something similar happened a decade ago with cloud computing. At first, the strategy and benefits were understood as simply renting compute power from a third party. “Cloud is just someone else’s computers” was a common refrain among IT professionals. This was true enough at first, when moving to the cloud was done as a “lift-and-shift” strategy. This meant you should take one app, run it on similar platforms in the cloud, save a few bucks, repeat. However, very quickly some very innovative companies realized that the flexibility, scalability and number of new services provided by public cloud vendors meant that applications would have to be re-architected to exploit these possibilities. The software industry is still discovering all the possibilities of the resulting SaaS models. Salesforce, Netflix, Amazon and a few others saw the possibilities, built their apps and services, and the rest of us are still learning.

At Cimetrix we have some experience working with manufacturers who are stepping into this area of I4.0 / cloud confluence. Our sense is that the conversations occur along the similar lines of pursuit. The first topics of conversation revolve around fear – security being the chief concern. How can a factory allow its data to leave the four walls? Two recent events have made this argument easier to overcome: TSMC had to shut down a major part of its operations in the summer of 2018 when a computer virus, installed on a new tool, spread to many other hosts. Hundreds of millions of dollars in shipment delays and other costs resulted from a breach of what had previously been thought to be a secure factory environment. On the cloud side: The Capital One breach, where one million social security numbers were stolen, had initial headlines that related it to the Amazon cloud. Since then, the bank has admitted fault and it has become clear that AWS services are secure.

Two critical elements important to the security argument are 1) employing talented security professionals and 2) deploying critical security patches as soon as vulnerabilities are discovered. The public cloud vendors recognized this long ago and hence their data centers employ security measures beyond the affordability of most business. Factories that continue to host their applications on premises, as opposed to the cloud, are increasingly competing with cloud vendors for security talent. These cloud vendors have massive scale and are still growing at ~40% per year. The result of this is that your apps and data are increasingly safer in the cloud than on an “on-prem” server.

Once these fears are assuaged the next line of reasoning tends towards identifying opportunities. This is where Cimetrix is uniquely positioned. We have the expertise to connect factory equipment, get the data into the cloud, and show our customers how to begin exploiting these technologies. Very often the first step is simply to connect as much factory equipment as possible, get a few simple messages, and expand later. This option has proven very fruitful for distributed supply chains that utilize contract manufacturing and outsourcing. Knowing the rate at which equipment is being utilized, which can be done with as few as two simple messages, can be extremely useful. Negotiating capital budgets for new products tends to improve when utilization rates for existing equipment are well known to all parties. The ROI for projects like this tends to be of the scale of months or weeks, not years.

After proving the ROI this way, with only a few simple messages, the next steps typically involve gathering more data. This is where the real power of cloud computing can be brought to bear. Smart factory computing implies the application of intelligence at the factory level to create a dynamic production environment where reducing costs and improving quality happens extremely quickly. Machine learning and very good AI tools are being developed now by the public cloud companies and to this author seem to be perfectly suited to factory data. “Big data” doesn’t get much bigger than the myriad of sensors already at work in a typical factory, pumping out immense amounts of data. Getting this data into the cloud and closing the loop back to factory equipment will benefit the first adopters in ways similar to the early cloud computing innovators.

Ten years ago innovative companies made a kind of leap, and re-architecting applications for the cloud brought large benefits. We see a similar leap coming for manufacturers who are willing to innovate with the help of these new cloud services. It’s not difficult to imagine how Amazon’s ecommerce engine has benefited from customer data to recommend just the right brand of beer to an on-line buyer of a Manchester United t-shirt. A data scientist I knew once said, “the algorithm says that when it’s raining in England we should recommend this beer. I don’t care why as long as it sells.” This same algorithm is on its way to a factory near you. Although instead of online conversions of browsers into buyers, these algorithms will be tweaked to focus on yields, cycle times, and utilization rates.

There are many other arguments for cloud computing which we ignore here. Arguments in favor of availability, scalability, compliance, ease of deployment, etc. These are all true but better addressed in many other venues. This is likewise the case for Industry 4.0; it is a younger sibling topic as compared to cloud computing, but still better fleshed out in other writings. We at Cimetrix are confident that when we look back 10 years from now, the companies that innovate best at this confluence of technologies will realize an immense potential. 

To learn more, or to schedule a consultation, please click below.

 

For the last couple of years, we have published a number of beneficial series in this forum to help contribute to the understanding of many of the standards in the manufacturing industry. In case you missed some of them, we are going to re-cap and link to the most popular today.

GEM Features and Benefits

This series features 15 separate posts with videos and information on some of the most important aspects of the GEM (SECS/GEM) standard. This series is one of our most popular ever and was written by a number of the Cimetrix engineering team who have studied and practiced GEM for many years.

EDA Application and Benefits in Smart Manufacturing

With the adoption of the latest SEMI EDA (Equipment Data Acquisition, also known as Interface A) standards accelerating significantly over the past 2 years, we felt it was time to highlight the applications across the industry that make the best use of these standards, and the specific manufacturing benefits that result. 

Models in Smart Manufacturing

In this series, we highlighted the importance of explicit and standardized models in the context of equipment communications interfaces and some of the “smart” factory applications they support. 

EDA Testing

Since the EDA/Interface A adoption process has now clearly reached critical mass, we must seriously address the question “How are we going to test the equipment and systems that incorporate these standards?” This is an excellent question, and one that has a multi-part answer, which is addressed in this 6-part series.

These, and many others including a the Cimetrix Book Club and Meet-the-Team series are some of what you can find on our blog. Be sure to subscribe today!

The Cimetrix Resource Center is a great way to familiarize yourself with standards within the industry as well as find out about new and exciting technologies.

Our resource center features information about equipment connectivity and control, data gathering, GEM (SECS/GEM), EDA/Interface A, and more. These standards are among the key enabling technologies for the Smart Manufacturing and Industry 4.0 global initiatives that are having a major impact on the electronics assembly, semiconductor, SMT and other industries. Manufacturers and their equipment suppliers must be able to connect equipment and other data sources, gather and analyze data in real time, and optimize production through a wide variety of applications. The videos and video series featured in our resource center provide in-depth coverage of some of these concepts.  Some of our featured videos are below.

• Smart Manufacturing Series by Ranjan Chatterjee
• What Happens in a Gigafactory Minute
• Cimetrix at IPC Apex 2019
• The Big Picture: EDA Overview and Mechanics

Be sure to stop by our Resource Center any time or watch the videos directly from the links in this posting.

The old adage “You get what you pay for” doesn’t fully apply to equipment automation interfaces… more accurately, you get what you require, and then what you pay for!

This is especially true when considering the range of capability that may be provided with an equipment supplier’s implementation of the EDA (Equipment Data Acquisition, also known as Interface A) standards. Not only is it possible to be fully compliant with the standard while delivering an equipment metadata model that contains very little useful information, the standards themselves are also silent on the topics of Performance and Data Quality.  So you must take extra care to state these requirements and expectations in your purchase specifications if you expect the resulting interface to support the demands of your factory’s data analysis and control applications. Moreover, to the extent these requirements can be tested, you should describe the test methods and tools that you will use in the acceptance process to minimize the chance of ugly surprises when the equipment is delivered.

We have covered the importance of and process for creating robust purchase specifications in a previous posting. This post will focus specifically on aspects of Performance and Data Quality within that context.

Scope of Performance and Data Quality Requirements

From a scope standpoint, Performance and Data Quality requirements are found in a number of sections in an automation specification. The list below is just a starting point suitable for any advanced wafer fab – your needs may extend and exceed these significantly.

Here are some sample requirements that pertain to the computing platform for the EDA interface software:

• The interface computer should have the capability of a 4-core Intel i5 or i7 or better, with processing speed of 2+ GHz, 8 GB of RAM, and 500 GB of persistent storage with at least 50% available at all times.
• The equipment must monitor key performance parameters of the EDA computing platform such as CPU utilization (%), memory utilization (GB, %), disk utilization (GB, %) and access rate, etc. using system utilities such as Perfmon (for Windows systems) and store this history either in a log file or in some part of the equipment metadata model.
• The network interface card must support 1 GB per second (or faster) communications.

In the area of equipment model content, the following requirements are directly related to interface performance and data quality:

• The equipment should make the EDA computing platform performance parameters available as parameters of an E120 logical element that represents the EDA interface software itself.
• The supplier must provide a written description of the update rates, recommended sampling intervals, normal operating ranges and behaviors, and high/low/rate-of-change limits for all key process parameters. These will be used to design data quality filters in the data path between the equipment and the consuming applications/users.
• Equipment parameters provided through the EDA interface must exhibit a number of data quality characteristics, including, but not limited to: an internal sampling/update rate sufficient to represent the underlying signal accurately; timing of trace reports that is consistent with the sampling interval within +/- 1.0%; values in adjacent trace reports must contain then-current values at the specified sampling interval; and rejection of obvious outliers.

Advanced users of the EDA standards are now raising their expectations for the equipment to provide self-monitoring and diagnosis capability in the form of built-in data collection plans (DCPs), as expressed in some of the following requirements:

• The supplier must provide built-in DCPs to support common equipment performance monitoring, diagnostic, and maintenance processes that are well known to the supplier. Documentation for these DCPs must define their purpose, activation conditions, interface bandwidth consumed, and the types of analysis the collected data enables.
• The supplier must describe the operating conditions that can lead to a PerformanceWarning situation for the EDA interface.
• The supplier must describe the algorithms used to deactivate DCPs under PerformanceWarning conditions. These might include LIFO (i.e., the last DCP activated is the first to be deactivated), decreasing order of bandwidth consumed or “size” (in terms of total # of parameters and # of trace/event requests), etc.

Because of the power and complexity of the DCP structure defined in the EDA standards, it is not sufficient to specify the raw communications performance requirement as a small number of isolated criteria, such as total bandwidth (in parameters per second) or minimum sampling interval. Rather, since the EDA interface must support a variety of data collection client demands for a wide range of production equipment, these requirements should be expressed as combinations of sampling interval, # parameters per DCP, # of simultaneously active DCPs, group size, buffering interval, response time for ad hoc “one-shot” DCPs, maximum latency of event generation after the related equipment condition occurred, consistency of timestamps in trace reports with the specified sampling interval, and perhaps others.

Moreover, some equipment types may have more stringent performance requirements than others, depending on the criticality of timely data for the consuming applications… so there may be process-specific performance requirements as well.

Measurement and Testing

Methods for measuring and testing the above requirements should also be described in the purchase specifications so the equipment suppliers can know they are being successfully addressed during the development process and can demonstrate compliance before and after shipping the equipment. Clarity at this phase saves time and expense later on.

Examples of such requirements include:

• The supplier must test the EDA interface across the full range of performance criteria specified above and provide reports documenting the results.
• An earlier requirement states that the EDA interface must be capable of reporting at least 2000 parameters at a sampling interval of 0.1 seconds (10Hz) with a group size of 1, for a total data collection capacity (bandwidth) of 20,000 parameters per second. In addition to this overall bandwidth capability, the supplier must demonstrate that this performance is possible over a range of specific data collection deployment strategies, meaning different #s and sizes of DCPs, different sampling intervals, group sizes, etc. without causing the EDA interface to reach one of its “Performance Warning” states or overstress its computing platform. To this end, all combinations of the following data collection configuration settings must be run for at least 15 seconds each; assuming the equipment has n processing modules:
  • Trace intervals (in seconds): 1, 0.5, 0.2, 0.1 (and 0.05 if possible)
  • # of parameters per DCP: 10, 50, 100, 250, 500, 1000 (and 2000 if possible)
  • # of DCPs: 1, 2, 3, … to n
  • Group size: 10, 5, 2, 1
• The test client should be run on a separate computing platform with sufficient computing power to “stay ahead” of the EDA interface computer; in other words, the EDA interface should never have to wait on the client system.
• Test reports should indicate the start and stop time of each iteration (i.e., one combination of the above settings), and verify that the timestamps of the data collection reports sent by the EDA interface are within +/- 1% of the value expected if the samples were collected exactly at the specified trace interval.

Performance parameters of the EDA interface platform should also be monitored during the tests and included in the report. These parameters should include memory usage, CPU processing load, and disk access rate (and perhaps others) for all processes that constitute the EDA interface software.

This approach is shown in tabular form for a 2-chamber tool (see below); since Group Size does not (or should not) impact the effective parameters per second rate, it is not shown in the table.

• A summary report for all performance tests that show acceptable message generation and transmission timing across the full range of data collection test criteria must be available.
• Detailed SOAP logs for specific performance tests must be available on request.

In Conclusion

We hope you now have some appreciation for the importance of solid requirements in this area, and can accurately assess how well your current purchase specifications express your actual needs. If you want to know more about a well-defined process for improving your specifications, or have any other questions regarding the status and outlook of the EDA standards, and how they can be implemented, please contact us.

Today is our next edition of the Cimetrix Book Club. Our employees are always striving to develop their skills, share information, and keep up to date with the industry. Part of this effort includes an employee book club that involves many of our team members each month. We will cover some of their favorites from time-to-time here on our blog!

Today's book is called "Microsoft Visual C# Step by Step – Eighth Edition" by John Sharp. The book review is by Richard Andrew, a Software Engineer based in Salt Lake City, UT, USA.This book was designed to be an overview of the programming language, C# and cover the breadth of most topics while delving in depth on some of the topics.  It was designed to be helpful for even the most novice developers while still being useful to advanced programmers looking to sharpen their craft.  This was perfect for our group because we had a mix of aspiring developers (or developers who hadn’t spent much time programming yet), experienced developers who were new to C#, and experienced developers just looking to get better and learn new things about the language and about best practices.

The Book was split up into four sections. The first two sections focused on general programming practices and structure that are important to any programming language but written in a way that was applicable for C#. These sections mainly focused on breadth and covering many topics. This was especially helpful for our aspiring developers and the developers who were just learning or becoming familiar with C#. For our more experienced developers, these sections were more of review or relearning what they already knew.

Section three dove deeper into more advanced programming topics and provided a good overview for some of our novice developers, but it was really geared for a more experienced developer. This section talked about generics, collections, event handling and querying expressions. Lots of new tools to add to our kits.

Section four focused primarily on building Graphical User Interfaces (GUIs) with C#, and the author specifically chose to highlight using UWP applications (Universal Windows Platform). This section on the surface seemed to be less relevant to what we were working on. But after reading and looking looking at the code behind it, it became very relatable to WPF (Windows Presentation Foundation), which is an application we use in our products. This section was also extremely helpful for anybody seeking to become Microsoft Certified. As we currently have several engineers in our group striving to become Microsoft Certified, this section was helpful preparation. 

All in all this book was excellent for our team. It gave an introduction and an overview to our novice developers while still providing a lot of education to our more experienced developers. A great thing about this book were the examples in each section that, when we really dug in, gave us rich knowledge and context to everything the author was trying to convey. You really get out what you put into the study of this book. 

SEMICON West 2019 has come and gone! The annual trade show and technical conference was held this year at Moscone Center in San Francisco and turned out to be a very busy time for the Cimetrix team. The trade show lasted three days and filled two halls, including the newly renovated South Hall. We had many meetings with current clients, met with new potential clients and even made a few new friends along the way.

This year has been an interesting one, with the semiconductor capital equipment industry seeing a downturn. In January at ISS, the consensus was the trough for semiconductor capital equipment makers would be Q2 with growth returning in Q3 and Q4. Now, the consensus is the recovery in the chip memory market and manufacturing expansion may not happen until mid-2020. However, people also say the visibility is only for the next 3-6 months, so this could change. Many of our customers are affected by this downturn – the severity varying by their customer base and territory. Customers that are focused solely on semiconductor 300mm wafer fabs with a strong exposure to memory, have been hit the hardest with declines in revenue up to 50% from 2018 levels. Customers that have more diverse product lines and sell to semiconductor back-end or electronics markets are doing much better. While this downturn is affecting our customers to varying degrees, we had many executive meetings with virtually all of them expressing continued satisfaction and appreciation regarding the high quality of our products and technical support.

We also had two speakers at the Meet-the-Experts tech stage within the Smart Manufacturing Pavilion. Brian Rubow, Director of Solutions Engineering, spoke on how to get the most out of the GEM standard, including following what the standard says and fixing implementations using sound software practices. You can view his presentation here. Alan Weber, VP of New Product Innovations also spoke on Addressing Connectivity Challenges of Disparate Data Sources in Smart Manufacturing, addressing the road to the smart, digital and connected factory. You can view his presentation here.

Cimetrix continues to strengthen our relationship with SEMI by our global leadership and participation in SEMI standards meetings as well as our sponsorship of the Smart Manufacturing Pavilion. We sponsored a kiosk in the Pavilion where we connected our new Sapience platform for Smart Manufacturing to a BTU reflow oven, which generated quite a bit of excitement.

SEMI Standards meetings continue to be a priority for Cimetrix. We are well represented at the standards meetings by chairing/co-chairing various committees and attending/participating in others. The following are some of the areas of significance.

• The DDA task force continues to develop EDA Freeze 3 standards with adoption of cutting edge gRPC technology to improve performance.
• The Fab & Equipment Computer and Device Security (CDS) Task Force received approval for two SNARFs (Standards New Activity Report Form) - "SNARF: Specification for Application Whitelisting" and "SNARF: Malware Free Equipment Integration". The SNARFs were created by the CDS task force and approved by the Information and Controls global technical committee which Brian co-chairs.
• The North American Information & Control Committee at SEMI established a new task force Advanced Backend Factory Integration (ABFI) to define and update standards to meet the needs of the semiconductor backend industry. Brian Rubow from Cimetrix, Dave Huntley from PDF Solutions are two of the task force co-leaders.

During the SEMICON West show, an article was published, written by Cimetrix VP and GM, Smart Factory Solutions Ranjan Chatterjee and Dan Gamota, VP, Manufacturing technology and Innovation for Jabil. The article called “Smart Manufacturing Roadmap: Data Flow Considerations for the Electronics Manufacturing Industry” can be found here. This article identifies technology gaps and needs, and offers recommendations to guide the electronics manufacturing industry in realizing the benefits of smart manufacturing and is sponsored by iNEMI. Mr. Chatterjee and Mr. Gamota are co-chairs of the new smart manufacturing chapter of iNEMI.

The Cimetrix team was excited to once again be an exhibitor and sponsor of the SEMICON West show. This is always a great show and we were very pleased to attend once again. We are already looking forward to SEMICON West 2020!

To view the presentations from SEMICON West, and many more, click on the button below.

SEMICON West is almost here and we’re excited to once again be participating this year as both an exhibitor and as a sponsor of the Smart Manufacturing Pavilion! Visit us any time at our booth 1644 in the South Hall, at our kiosk (#1364) in the Smart Manufacturing Pavilion, or at the Meet the Experts Theater which will feature Cimetrix speakers on Tuesday and Wednesday.

SEMICON West will once again be held in the Moscone Center in San Francisco, CA, USA from July 9-11. The theme this year is “Insight, Innovations & Intelligence: Our industry – and the world – is moving beyond smart.” We couldn’t be more excited about the momentum of the semiconductor industry. As Industry 4.0 and the demand for Smart Manufacturing solutions have become more prevalent, we’ve seen our market expand beyond the equipment manufacturers to encompass all phases of the electronics manufacturing process and corresponding elements of the supply chain. To achieve a smart, connected factory, you must first have equipment that can communicate effectively, which is where Cimetrix has always excelled. Our well-known and award-winning products enable every semiconductor manufacturer in the world to connect their equipment to the factory information and control systems. SEMICON West has always been an important event for meeting with current clients, making new contacts, collaborating in the SEMI Standards community, and developing relationships with thought leaders across the manufacturing spectrum.

The rapid and continuous growth of manufacturing data is now driving demand for new analysis technologies that can further leverage its value. The Smart Manufacturing Pavilion is a great place to see some of the breakthroughs that are creating smarter processes and spurring innovation across the industry.  The pavilion once again includes a Meet the Experts Theater, and Cimetrix has two opportunities to address the audience. Brian Rubow, Director of Solutions Engineering, will speak on “Getting the Most from the GEM Standard” on Tuesday July 9 from 1:30 – 2:00 pm. Alan Weber, VP of New Product Innovation, will talk about “Addressing the Connectivity Challenges of Disparate Data Sources in Smart Manufacturing” on Wednesday July 10 from 3-3:30 pm.  

The Smart Manufacturing Pavilion and its Meet the Experts Theater are in the South Hall and we hope to see you there! Or, as always, you can visit our booth 1644 any time during the show.

Cimetrix attended the recent JISSO PROTEC exhibition (June 5-7, 2019) at the Tokyo Big Sight International Exhibition Center to see the latest developments in SMT (Surface Mount Technology) manufacturing… and witnessed a truly compelling demonstration of the new SEMI Flow Manufacturing communications standards in action.

The new suite of standards is named SMT-ELS (Surface Mount Technology-Equipment Link Standards), and includes SEMI A1/1.1 as a lower-level messaging standard with SEMI A2 SMASH (Surface Mount Assembler Smart Hookup) defining the content of the messages required to configure an SMT manufacturing line and automate the material and information transfer among all equipment in that line. This is depicted in the figure below.

The demonstration itself included placement equipment from 4 large equipment suppliers—Fuji, JUKI, Panasonic, and Yamaha—as well as load/unload stations and a bar code reader at the beginning of the line (see picture below). Each of these companies had implemented the “horizontal” (machine-to-machine) communications according to the SMT-ELS standards. The demonstration consisted of an operator scanning one of the stack of input boards with the barcode reader, placing it on the loader conveyor, and then watching as each piece of equipment automatically adjusted its internal conveyor to accept the board, run through its part placement recipe, and pass the board to the next equipment in the line, finally arriving at the unload station conveyor after a minute or so.