Industry News, Trends and Technology, and Standards Updates

On Friday, August 18, Cimetrix held its Annual Meeting of Shareholders at our headquarters in Salt Lake City, UT. We were excited that sixty percent of Cimetrix shareholders were represented at the meeting. There were two proposals submitted by management and both approved, receiving over 90% of votes cast.

After the formal shareholder meeting was adjourned, Dave Faulkner, Executive VP of Sales and Marketing, gave a presentation on our Cimetrix products and markets. Following Dave’s presentation, Bob Reback, President and CEO, provided his perspective on the state-of-the-company and outlook going forward. 

We appreciate all of our shareholders and are grateful to those that attended the meeting either in person or via proxy. As always, we thank our shareholders for their continued confidence and support.

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:

Read more about High-Speed SECS Message Services
Download the white paper on the SECS/GEM Standards

Join us as we meet the Leadership Team of Cimetrix in our “Meet the Team” series.

Richard Howard - Director of Technical Operations—has over 30 years of experience in both vertical and custom software development, and has been with Cimetrix since 2011. Howard previously worked for Murata Machinery USA/ICIS, Inc. as a Senior Software Engineer and Principle Software Engineer. During that period, he worked with large companies such as Honda, Fuji Film, Jet Blue, Fed Ex, Ford, Sony as well as many others involved in manufacturing and distribution. He also has been in various roles for firms developing software for credit unions, banks, insurance, leasing, home automation and medical records. He has degrees in Business and Engineering from the University of Utah and is a Professional Scrum Master.

-----

What brought you to Cimetrix originally?

I spent a large portion of my career working in the Automated Material Handling System industry. There is something about controlling equipment with software that I found intriguing. When I left that industry, and tried working in businesses that didn’t involve equipment control, I found myself bored and unchallenged.  When I saw an opportunity to get back with a small company that was involved with equipment control, I jumped at it. 

What's your favorite thing about working here?

The people at Cimetrix.  Our team is comprised of the best group of people I have had the privilege of working with, both professionally and personally, in my life.

Your role at Cimetrix has covered a few different areas over the years. What do you enjoy most about your current position?

Two things:  1.  I get to work with the entire organization and everyone in it. 2. The work is always challenging.  

Do you have a favorite saying? Why?

My favorite saying is one my father used to say to me through my teenage years: “No matter what you do in life, always do a good job and learn everything that you can.” I have found great wisdom in those words as I have advanced through life.

How do you deal with challenges that come up in your work life?

The only thing you really can do, address them as they arise.  If there were no challenges, what would be the point of getting out of bed in the morning?

What do you like to do in your free time?

I have several hobbies that I rotate between depending on my mood.  I like to golf and enjoy getting out as much as possible.  I like cooking, home remodeling projects, woodworking, attempting to play musical instruments and, of course, being a grandpa.

What's the best thing that's happened to you in your time working at Cimetrix? 

The best thing was joining Cimetrix.  I have enjoyed every opportunity and every challenge that I have been given.  I like to get up each morning and get to work.  Working at Cimetrix is great!

-----

…never mind which came first… do you know where the chicken and the egg came from?

As integrated circuits increasingly find their way into applications for which human and environmental safety are paramount, the regulatory requirements related to product traceability become ever more stringent. For example, the automotive industry already requires that a device maker be able to provide a full manufacturing process history within 48 hours of a request for certain kinds of products, but this only scratches the surface of what’s to come in the growing markets for autonomous vehicles and their supporting public infrastructure, aircraft components, medical implants and diagnostic systems, and the like.

The good news in all this is that the latest semiconductor manufacturing equipment interface standards include enough information about the product being built and the processes used at each step along the way to directly support these traceability requirements with little or no custom software. Specifically, the SEMI Equipment Data Acquisition (EDA) suite of standards (also known as “Interface A”) defines the components of an explicit equipment model that can represent this information, and the SEMI E164 (EDA Common Metadata) standard goes so far as to specify the actual structure and naming conventions for the required components.

Before getting deeper into the specifics, let’s step back and define “traceability” in this context. According to ISO 9000 (Quality management systems – Fundamentals and vocabulary), the term means “the ability to trace the history, application or location of an entity by means of recorded identifications.” 

In a wafer fabrication facility, this definition covers a broad range of capabilities. The most basic interpretation could be satisfied by simply having an ordered list of the manufacturing equipment visited by each wafer (substrate) during its 3-month journey through the fab. As long as the manufacturer keeps a record of which substrate each assembled die came from (which most do), the required documentation could be generated from information contained in the MES (Manufacturing Execution System) and its associated scheduling/dispatching system. 

However, at the other end of the spectrum, the traceability requirement may include not only the list of equipment visited, but also the recipe used at each equipment, the precise timing of wafer movement and process modules visited within the equipment, values of any adjustable recipe parameters and/or equipment constants that affect process behavior, batch identification and status information for any consumables used during the process, usage counts for any fixtures involved, operator interactions (if any), and so on. The reason for this level of detail is to enable the failure analysis engineers to identify the potential root causes for any field failures, and then determine what other devices in the field may be susceptible to similar failure conditions for product recall purposes.

To be sure, much of this information could be assembled after-the-fact from the various data bases maintained by the equipment and process engineering and yield management systems present in most modern wafer fabs, but this process can be complex, time-consuming, and error-prone. A better approach would be to generate the most commonly needed traceability records on-the-fly directly from information available in the equipment... and this is where the newest EDA standards enter the picture. 

By analogy, let’s look at an intuitive example: a commercial cake baking enterprise. Even for a relatively simple (compared to semiconductor manufacturing) production process, full traceability requires information from the raw materials suppliers through the manufacturing process to packaging and finished goods warehousing. You can see in the picture below that material, recipe, and equipment setup information is included in the records produced.

In a unit of semiconductor manufacturing equipment with an E164-compliant interface, these types of information appear in various sections of the equipment metadata model. Specifically, material-related information is captured in the “Material Manager” logical component, shown in expanded view below* to highlight the state transition events and parameter data available for each substrate during its transportation and processing in the equipment.

Recipe-related information is found in the physical modules responsible for substrate processing (“ProcessingChamber1” and “ProcessingChamber2” in the example below), within the “E157-0710:ModuleProcess” state machine, dictated by the SEMI E157 (Module Process Tracking) standard and required by E164. Note the rich list of context information available at every recipe step, including the RecipeParameters array, in the expanded model excerpt below. Taken together, the timing and parameter data from these two sections of the equipment model supply most of the information required for full wafer fab traceability. Moreover, since SEMI E164 actually standardizes the event and parameter names in the model, the DCPs (data collection plans) that collect this information can be programmatically generated and activated for all the equipment that is E164-compliant. This represents a significant engineering cost reduction over the conventional methods used to identify, collect, and manage this information. The figure below is one visualization of such a DCP.

When extended beyond individual devices to circuit boards, modules, and completed parts (see the example below for an automobile speedometer), these requirements require even more bookkeeping… but that’s a topic for another day!

This article is the fourth in the series recently announced in the Models in Smart Manufacturing Series - Introduction, be sure to watch for subsequent postings that will expand on this theme. 

We look forward to your feedback and to sharing the Smart Manufacturing journey with you.

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

In a world of automated equipment, having tools to automate the testing of an equipment’s implementation of the SEMI EDA (Equipment Data Acquisition) standards (also known as Interface A) is invaluable. Cimetrix is proud to announce an integrated solution that supports the broadest range of use cases in EDA/Interface A testing - the Cimetrix EDATester™. EDATester is a tool that will help organize, streamline, and automate the testing process while also providing other analytical capabilities. 

Cimetrix knows that testing an equipment interface is not simply a one-time event; rather, tests should be performed in the OEM’s facilities throughout the development process and before final shipment, upon delivery to the customer’s factory, and even after the equipment has been placed into full production. Cimetrix EDATester is designed to do exactly that.

What do we really mean by “testing?” What are we testing? Since the scope is very broad, let's frame the answer in a few distinct categories.

Compliance Testing

Does the equipment’s EDA interface behave correctly based on the SEMI E120, E125, E132, and E134 standards and all the services defined therein? To answer this question, we make use of the ISMI EDA Evaluation Method. This document contains a set of functional evaluation procedures that “tests” the equipment’s implementation of the standards. These procedures check for things like ACL privileges and roles, establishing and terminating communications sessions, managing (or preventing the management of) Data Collection Plans (DCPs), and even looking for the proper notification of metadata revisions. If everything works as expected in these procedures, that equipment would be deemed “compliant.”

EDATester uses ISMI’s functional evaluation procedures as guidelines, and implements tests that are automated for all client-side actions. A process that might have taken multiple days to execute manually can be done in minutes, even when some interaction with the equipment itself is required; the fully automated tests that require no user interaction with the equipment can be run in seconds.

Performance Testing

Everything might look great on the client side with the ability to define a DCP, activate it, and start receiving data; but how many DCPs will the equipment actually support? How fast can I sample the parameters I want to collect in my Trace Requests without overloading the equipment’s EDA interface? Even if I could do this manually, how would I begin to answer this question?

EDATester automates multiple iterations of performance testing using different variations of DCPs while analyzing the timestamps of the E134NewData messages to determine the integrity of the actual sampling rate. Having such tests helps you determine whether the equipment can handle a new DCP in response to a process engineering request, or if the equipment supports the full range of performance requirements agreed to in the purchasing specifications. To this end, you can specify testing configurations for things such as:

• Number of simultaneously active DCPs 
• Trace Request Sampling Interval
• Number of parameters per Trace Request
• Group Size for message buffering
• Timing tolerance for expected vs. reported Data Collection Report (DCR) timestamps

Conformance Testing

The testing tool in practical use across the industry for measuring an equipment’s conformance to the SEMI E164 EDA Common Metadata standards is called the Metadata Conformance Analyzer (MCA). It uses a set of .xml files describing the metadata model as input, analyzes the model according to the requirements of E164, and provides feedback.

EDATester currently generates the .xml input model files required by the MCA, and may eventually incorporate the model conformance testing functions as well.

Summary

Having the correctly sized wrench when you need to apply the proper torque to a bolt is helpful and sometimes necessary—at least you can get the job done. But when you have hundreds of bolts to insert and tighten precisely, wouldn’t you rather have an adjustable ratchet? Or an air ratchet?

Whether it’s to test and characterize the EDA interface on a new equipment type,  verify that a software update to a production piece of equipment has been installed correctly, or debug an interface performance issue that has somehow arisen in production, the Cimetrix EDATester is the right tool to have in your arsenal to quickly, effectively, and thoroughly “test” an equipment’s EDA interface capabilities. Don’t waste another day with manual processes that leave you guessing. Get in touch with us today to find out more about the EDATester product. 

SEMICON West 2017 has come and gone! The trade show and technical conference was held this year at the Moscone Center in San Francisco and turned out to be a very busy show for the Cimetrix team. While the show was only two halls strong, we had many meetings with current clients, met with new potential clients and even made a few new friends along the way.

A major highlight of the event for all of Cimetrix took place Tuesday evening at the SEMI Standards Awards reception where our own Brian Rubow, Director of Client Training and Support at Cimetrix, took home the prestigious SEMI Leadership Award. Brian, who has over 20 years of experience in the industry, has been a long-time leader and key contributor to the SEMI Standards programs throughout his career.  We were very proud of his work and so glad he was able to receive recognition from the SEMI organization. 

The sales team was hard at work during the entire show and it wasn’t often the Cimetrix booth was empty! Meeting with many new companies made the show very exciting. Our team was especially pleased to meet for several hours with the CEO of our newest client from China! The relationships we establish and cultivate while at these tradeshows make them an invaluable part of our sales, marketing and support efforts. 

The Cimetrix team members that attended were Bob Reback (President and CEO), Dave Faulkner (EVP Sales and Marketing), Ranjan Chatterjee (V.P. Emerging Business & Technology Office), Stu Benger (Director of Sales, North America), Brian Rubow (Director of Client Training and Support), David Francis (Director of Product Management), Alan Weber (V.P. New Product Innovations) and Kimberly Daich (Marketing Manager). Several team members were able to attend for just a day including some of our newest engineers. It was a great chance for them to get to know the show, meet some clients and see some of the machines our software powers in action.

The Moscone Center is undergoing major renovations in preparation for SEMICON West 2018; and we were able to secure a premium spot for next year’s show. SEMICON West is always a great show and we were pleased to be able to attend this year, and as always we’re already looking forward to SEMICON West 2018!

You may have noticed that there is a lot of positive news regarding the semiconductor industry and market for capital equipment. As such, we thought it would be appropriate to provide a mid-year update on Cimetrix’s performance.

We are pleased to report that Cimetrix is benefiting from a combination of the industry upcycle as well as the hard work of our employees to improve our products, build long-term relationships with our clients, and provide the highest level of support to our growing base of international clients. In addition, the benefits that Cimetrix is experiencing after going private in 2014 are higher than anticipated. As expected, the company is saving a significant amount per year in accounting, legal and consulting fees that were necessary for SEC filings, Sarbanes-Oxley compliance, and investor relations activities.  However, in addition to these financial benefits,  what we didn’t anticipate was the tremendous increase in focus and energy on our clients, markets and growth initiatives that has resulted, which has greatly exceeded our expectations.Cimetrix revenues for the first six months of 2017 were over $4M, up more than 40% year-over-year. Much of this increase was associated with strong increases in machine shipments from our growing client base. Cimetrix also gained over a dozen new design wins during the first half of 2017, which positions the Company for continued growth. In addition, Cimetrix introduced two new products in the first half of 2017, which have not contributed significant revenue yet, but are both gaining traction in the marketplace.

While Cimetrix no longer submits SEC filings, we have maintained strong internal controls and financial accounting. Our finance team was justifiably proud when a leading regional accounting firm completed its audit of our 2016 financial statements and made no audit adjustments. Cimetrix continues to operate profitably on a quarterly basis, while increasing investments in growth initiatives. For the first six months of 2017, adjusted EBITDA increased to over 15% of revenues to over $600K. All indicators show the markets Cimetrix serves should remain strong for the second half of 2017. The robust growth in revenues has enabled Cimetrix to further strengthen its cash position, balance sheet and stockholders’ equity. We continue to have no debt and now have $2.5M in cash.

Cimetrix continues to build its global brand as the leader in innovative factory automation software for equipment connectivity and control solutions by attending, presenting and exhibiting at industry tradeshows and events. These venues are a great place to meet face-to-face with clients, reinforce Cimetrix experts as industry thought leaders, and interact with many others in our chosen markets. It is exciting to participate in shows around the world as we expand our global presence.

We thank our clients for their business and trust in our products and people. We thank our employees for their dedication, hard work and quest for continuous improvement to provide the industry’s best products and services. And we also thank our shareholders for the confidence they have placed in us, as well as their patience and support.

Generally, when I do a DIY (do-it-yourself) project around the house, I spend the majority of the time searching for my tools. The other day I was helping a friend with a project. He had a well-organized tool box and it seemed that the perfect tool was always at his fingertips. I was amazed at how fast the project went and how easy it was when the right tools were handy.

In April of 2016, we published a blog called OEM EDA Implementation Best Practices that outlined ten things to consider when designing an equipment-side EDA / Interface A solution to fit your needs. This blog post analyzes a few of those recommendations and looks at how using the Cimetrix EDA products CIMPortal Plus, ECCE Plus and EDATester (a well-stocked and organized tool box) makes it very easy to follow those recommendations.

The basic steps in creating a useful EDA implementation are:

1. Determine which data will be published
2. Build an equipment model
3. Deploy the model
4. Publish the data from the equipment control application
5. Set up a data collection application
6. Test the interface

The blog post mentioned above states, “Since the content of the equipment metadata model is effectively the data collection contract between the equipment supplier and the factory users, your customer’s ultimate satisfaction with the EDA interface depends on the content and structure of this model.” Before building your model, you need to determine what data the equipment will make available for collection. CIMPortal Plus has the concept of a Data Collection Interface Module (DCIM) that publishes this data to the EDA server. The engineer building the model will map the data from the DCIM into the equipment model.

Once the mapping of the data is complete, the engineer will need to put this data in a format understood by the server. CIMPortal Plus provides a utility called Equipment Model Developer (EMDeveloper – pictured below) that makes it easy to create the hierarchy of your equipment (SEMI E120) and embed the data from the DCIM into that model (SEMI E125). If you use the tools and best practices provided in EMDeveloper, your equipment model will conform to the SEMI E164 (EDA Common Metadata) standard as well. This can be very useful when writing data collection applications so conformance to E164 is being required by more and more fabs. The E164 standard was developed to encourage companies using Interface A connections to provide a more common representation of equipment metadata based upon the SEMI E125 Specification for Equipment Self-Description. This makes data collection more uniform across these pieces of equipment.

Once the model is created and validated, it is deployed to the CIMPortal Plus server. The server is the component that manages and tracks all data collection plans, reports, tasks, access control and timing. 

With the DCIM information embedded in the model (described above), it is easy for the equipment control application to push the data to be published to the EDA server for collection. This is done by using a simple API available on the DCIM interface.

In addition to CIMPortal Plus server capabilities, Cimetrix has other products available to help with client-side data collection. ECCE Plus is an industry approved method for manually testing EDA implementations. For users who need to create client-side data collection applications, Cimetrix also provides EDAConnect - a powerful library that handles all the connection details and allows developers to concentrate on the specific data collection and analysis tasks.

Fabs receive a wide variety of equipment with EDA implementations from numerous vendors. They want to use a single verification application to make sure that all EDA implementations are compliant to the EDA standards. That’s where EDATester comes in. EDATester is a new product that allows users to quickly and accurately verify EDA standards compliance by automating the test procedures ISMI EDA Evaluation Method that were defined specifically for this purpose. If you use Cimetrix products to implement your EDA interface, you are guaranteed to be compliant with the SEMI EDA standards. But whether you use Cimetrix products to implement your EDA interface or not, you (and your fab customer) want to rest assured that your implementation is fully compliant. Moreover, you’ll want to know that you’ve met the fab’s performance criteria for your equipment interface. To support this use case, the EDATester also allows users to quickly profile the performance of EDA data collection on a piece of equipment so that fabs and those using the data will know the boundaries within which they can successfully collect equipment data.

With the well-stocked EDA tool box provided by Cimetrix, following the EDA best practices in creating an efficient, standards-compliant EDA interface becomes a snap.

…or how to move away from “just in case” data collection...

It’s a common process engineering request of the manufacturing IT folks: “Please collect as much data as you can during this process, and we’ll figure out what’s important later.” And this approach has worked fairly well up to this point. However, with 10nm (and below) production on the horizon, coupled with the desire to sample key parameters at ever-increasing rates, the amount of on-line data storage required to support this approach could skyrocket… to say nothing of the difficulty in sifting through all that data to extract the real information you wanted in the first place.

Fortunately, you don’t have to look very far into the SEMI EDA (Equipment Data Acquisition) standards (also known as “Interface A”) to find an excellent solution alternative. The portion of the standard equipment metadata model (specified by SEMI E164 – EDA Common Metadata) that deals with process execution (SEMI E157 – Process Execution Tracking) combined with the conditional triggering features of Trace Requests (SEMI E134 – Data Collection Management) enables a process engineer to precisely collect the right data at the right time at the right frequency without over-burdening the equipment or factory systems by collecting and storing less important data at the highest rates. 

Let’s look at an example. The key state machine called for in the E157 standard (see figure below*) has 2 major states (NOT EXECUTING and EXECUTING) with intuitive transition events defined between them (Execution Started, Execution Completed, and Execution Failed). If you only care about tracking the overall execution time of the process recipes on a given tool, then a single DCP (Data Collection Plan) with a pair of Event Requests on the Started and Completed events is all you need. The difference in the timestamps of the corresponding Event Reports provides the necessary information. 

However, if you want to monitor a baseline set of equipment performance parameters at a low frequency (say, 1 Hz) throughout the recipe, and collect the key parameters for analyzing process behavior at a higher frequency (50 Hz) during the most critical process steps (5 through 8), you would use a DCP with multiple Trace Requests triggered by the Step Started and Step Completed transition events between the two sub-states (GENERAL EXECUTION and STEP ACTIVE) of the EXECUTING state. Furthermore, you would use the conditional triggering feature of the Freeze II version of the EDA standards (SEMI E134-0710 or later) to produce Trace Reports only during the critical process steps. The figure below is one visualization* of such a DCP.

You may have noticed from this example that multiple triggering conditions are ANDed together to determine whether or not to collect the data and generate a Trace Report. But how do you handle the situation in which OR functionality is needed to produce the desired result, for example, in the case that multiple sets of recipe steps are considered critical (say, steps 5-8 and steps 11-13)?

This is where you can use one of the “tricks of the trade.” Simply define multiple Trace Requests with different sets of ANDed conditions to cover the range of ORed situations. For the case above, you would need two Trace Requests: one for each critical set of contiguous recipe steps (see visualization below).

Note finally that you can also apply comparison operators to analog values to trigger Trace Requests, which may be especially useful to sample specific parameters when some value crosses an important threshold. 

Taken together, these techniques are sometimes called “data framing,” which is an important tool in the controlling the scope of factory data explosion that will soon be upon us. 

This article is the third in our Models in Smart Manufacturing series – be sure to watch for subsequent postings that will expand on this theme.

We look forward to your feedback and to sharing the Smart Manufacturing journey with you.

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

Have you ever had that itch you just can’t seem to ever get rid of despite all your scratching? Well, UI Testing is that same itch for many developers. Fortunately, Coded UI Test exists, allowing us to scratch that itch with ease and relieve the heartache that is UI Testing.

A very important part of our development process is testing our software to ensure that each product is the best it can possibly be for our customers. There can often be a lot to test in a short period. Having a fast, efficient, repeatable, and reliable way to make sure everything is tested is what we strive for. Coded UI Test (CUIT) allows us these attributes.

CUIT creates automated tests used for functionality testing of a GUI application. There are several ways to go about this, the first being the ‘Record and Playback’ feature that CUIT provides. This option allows us to set up tests by starting the recording feature and performing the tasks the developer would like to test. The recording feature will record everything the developer does and automatically generate a test for us. After it is generated we can play it back to run the test as many times as we want.

The recording feature alone is not the only option CUIT provides of course. However, the recording feature certainly does help when writing our own scripts when we want to go beyond the basic testing features available through the recording. Since the recording feature generates its own C# code, we can use those generated scripts to see how the CUIT works and expand on those scripts to fit our needs.

We can see in this generated code snippet how CUIT goes about looking for a button in a WinForms application. This button in the above sample is named ‘Refresh’ and once CUIT finds this button through this code snippet, we can do many different things with the button. This includes clicking the button, verifying the test in the button, seeing whether the button is disabled or not, and many other things we might want to check in our tests. Now with this code snippet in mind we can modify it to look for other buttons or other controls such as checkboxes, radio buttons, and other controls we might want to include in a test.

We want to be able to expand upon our tests through the help of our Software Engineers and not just our Quality Engineers. Thankfully, CUIT uses C# instead of a proprietary scripting language, making it easy for our Software Engineers to go from working on our applications to writing tests through CUIT for our applications. This enables us to collaborate effectively and make sure our products are being tested as best they can.

CUIT is a great way to develop sophisticated tests for our applications to assure our customers will be satisfied with our products. We will continue to create more tests within CUIT to help us make sure no new bugs are introduced. The more tests we can automate through CUIT, the faster and more efficient our testing process will be and the easier it will be for us to identify potential problems if they arise, helping us create a product we can continue to be proud of.