Industry News, Trends and Technology, and Standards Updates

Background and Audience

Over the past several years, I have written numerous blog postings heralding the benefits of the SEMI Equipment Data Acquisition (EDA, also known as Interface A) standards, promoting their adoption by 300mm wafer fabs around the world, explaining how to develop robust purchase specs to ensure the interfaces delivered by the equipment suppliers meet the fab customers’ expectations, describing how the various components of the standards work together and the importance of the embedded equipment model, and finally explaining how to run compliance and performance tests on an EDA interface to validate its fitness for production use. The target audience for most of these postings has been the factory users, for they are the ones who increasingly depend on detailed equipment and process data to profitably run their enterprises.

By contrast, this posting is aimed at the equipment suppliers who are looking to increase the value of their product families by augmenting their hardware offerings with software capabilities that only they are uniquely qualified to provide.

This is not a new idea. Several major equipment suppliers have offered so-called “Equipment Engineering Systems (EES)” products as companions for their equipment over the years, providing applications like Fault Detection and Classification (FDC), production monitoring, maintenance management, local repositories for diagnostics and field support, and other capabilities that leveraged deep domain knowledge of the equipment. However, these systems necessarily relied on private interfaces to the equipment for their data, such as an additional network connection, direct access to the file system, or other mechanisms. And from the fab’s perspective, these constituted yet another piece of infrastructure to maintain.

Now there’s EDA: a key enabler for value-added equipment applications

Since the SEMI EDA standards are inherently multi-client, a single EDA interface can support not only the factory information and control systems that depend on equipment data, it can also provide whatever information a supplier-specific application may need as long this data is represented in the equipment metadata model. Since that model is designed by the equipment suppliers as a fundamental component of the EDA interface, they can choose to put as much information in these model as they want, possibly well beyond that required by the fab customers’ purchase specifications. In fact, these models could be used to implement the diagnostic logging capability that suppliers usually build into their equipment for their own use, but without requiring custom software to read and interpret that information. See the figure below for an example of such a configuration.

The EDA standards also include a provision for “built-in DCPs” (DCP = Data Collection Plan) which can be shipped with the equipment and protected from accidental deletion at the factory site. These DCPs could be crafted by the equipment supplier to directly feed whatever value-added applications the supplier chose to develop, whether these resided on a computer local to the equipment in the fab, on portable computers used by field service engineers to diagnose problems, or on remote cloud-based systems allowed to connect via secure EDA-defined URLs. This flexibility opens up a wide range of application types, from those that embed equipment-specific algorithms to generic Machine Learning frameworks… the possibilities are endless.

What all these approaches have in common is a standard EDA client capability that can establish a session with the equipment, activate Data Collection Plans, and receive the ensuing Data Reports. The EDAConnecter within the Cimetrix Sapience platform provides all these features and more in a lightweight set of .NET libraries which can be deployed wherever they are needed to consume EDA data.

Conclusion

More and more semiconductor factories are requiring EDA interfaces with their new equipment purchases with highly prescribed equipment models and demanding performance criteria. From the equipment supplier’s perspective, these requirements have been viewed as a source of additional cost, with all the benefits accruing to the factory customers. But it doesn’t have to be that way…

Why not take advantage of this interface to offer additional value using a standards-based approach? This just might be an idea whose time has finally come. If you agree, give us a call – we can help you make it happen!

Today’s blog posting highlights the latest and most recent activity with the Cimetrix Book Club. Our employees constantly strive 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, and from time to time we cover some of their favorites here on our blog!

Today's book is titled "The Art of Unit Testing" by Roy Osherove. The book review is by Westley Kirkham, a Quality Engineer based in Salt Lake City, UT, USA.

“The Art of Unit Testing” guides the reader step by step from writing the first simple tests to developing robust test sets that are trustworthy, maintainable and readable.

In the first section, Osherove explains what a unit test is, the properties of good unit tests, and why they are so important. The lion's share is dedicated to the nitty-gritty of writing and maintaining unit tests specifically, and testing suites generally. The first part of the section goes in depth to show how Mocks, Stubs and Isolation frameworks are used to test your code. The last section discusses how to deal with resistance to change from co-workers and management if you're trying to introduce Test-Driven Development or Agile methodologies, as well as how to deal with legacy code. Osherove also shares his insights on what tools he believes are the best aids in unit testing. ReSharper is one of his favorites, but he also reviews Nsubstitute, Moq, CodeRush and others.

One section that stood out to our team was Osherove's three pillars of a good unit test—trustworthiness, maintainability, and readability.

Trustworthy tests are up-to-date, simple and correct. There are no duplicate tests, and they do not test any old functionality or functionality that has been removed. The unit test only tests one item and doesn't conflict with other tests. The bugs the test finds are actual bugs in the code, and not bugs in the test.

Maintainable tests are flexible, and don't break with each minor change to the product. The tests are isolated. They are not over-specified and they are parameterized.

Readable tests are easy to understand and do not require the developer or tester who comes after you to spend extra time understanding what you've written. The test names are descriptive, and the asserts are meaningful. Any failures or issues caught will lead the developer in the right direction.

These three pillars should apply to all that we write, not just tests.

At Cimetrix, much of what Osherove teaches is already integrated into our engineering culture. As part of our implementation of Agile, developers write unit tests to verify that the functionality they have coded is correct. It is then reviewed by another developer and a member of the QE team to ensure that common use cases and important edge cases are covered and that the functionality is complete. All code must follow naming conventions and styles verified through ReSharper. For all of our products, unit tests are run on each build, and integration tests are run nightly.

Osherove's lessons on unit testing implementation, testing suite organization, and test-driven development integration are simple and practical. This book would benefit any team looking to improve the fidelity of its software products and the efficiency of its engineers.

Meet Richard Andrew, CCF Services Software Engineer at Cimetrix. Read on to learn a little bit more about Richard.

How long have you worked at Cimetrix?

I have been working at Cimetrix for just over two years now.

When did you graduate and what degree did you get?

I graduated from Utah Valley University with a Bachelor's of Science in Computer Science.

What drew you to Cimetrix originally?

I wanted to work on fun tools and equipment, and get to control robots!

What is your role at Cimetrix currently?

I am a Software Engineer on the CCF (CIMControlFramework) Services Team.

What do you think it means to a client to have a great CCF services team?

Having a great CCF services team means clients can either have Cimetrix do part or all of a project  and trust that it will accomplish what they need and they won’t have to worry about it. We value being able to give our clients peace of mind.

What do you like best about the work you do at Cimetrix?

I like the fulfillment I get when our customers are happy with our software and the work we do on our Services team.

What is something you’ve learned while working at Cimetrix?

I’ve learned how to be a better developer and how to work on various projects to accomplish unique goals. I’ve learned how to talk with clients, understand their needs and train them on how to best utilize our software.

What is one of the hardest challenges you’ve been faced with at Cimetrix and how did you overcome the challenge?

Becoming Microsoft certified required a lot of dedication and effort both in the office and outside.  It was like going to school full time and working full time at the same time.  I overcame it through dedicated studying, spending the time required, and taking lots of practice tests!

What is your favorite vacation spot?

I like to go fishing up in Alaska.

What do you like to do in your free time?

I like to play softball, play games, and spend times outdoors.

Background

Previous blog posting in this series have discussed the rationale for using SEMI’s GEM, GEM 300, and related automation standards in semiconductor backend factories, and pointed out that the specific adaptations required for the various backend equipment types are one of the focus areas for the SEMI Advanced Backend Factory Integration (ABFI) Task Force. In this posting, I will deal specifically with the benefits that can be realized by using the E157 Process Module Tracking standard in a backend factory context.

Since none of the backend material transformations are implemented in what front end experts would consider a “process chamber,” this may seem like an unlikely fit. Moreover, the velocity of backend processes seems contrary with the typical front end recipe execution paradigm. Finally, the lack of distinct substrate locations for some of the processes makes it difficult to know precisely when the process begins and ends for the affected material in some cases.

Regardless of these challenges, the requirements for single device traceability that include knowing the exact process conditions that a device was exposed to at every moment in its manufacturing life cycle (including the backend) argue for use of this standard wherever possible.Since none of the backend material transformations are implemented in what front end experts would consider a “process chamber,” this may seem like an unlikely fit. Moreover, the velocity of backend processes seems contrary with the typical front end recipe execution paradigm. Finally, the lack of distinct substrate locations for some of the processes makes it difficult to know precisely when the process begins and ends for the affected material.

SEMI E157 – Process Module Tracking

The purpose of SEMI E157 is “to define a standard equipment capability to report process-related data to the factory system… the activities of a processing location (i.e., process module) that are related to the execution of a recipe.” The standard further states that “the collection of process data during recipe execution is important to today’s semiconductor factories to support various applications that help optimize equipment processes, finished product quality, yield, and overall factory performance.”

These requirements are now every bit as important for backend factories as they are for the front end, so it is useful to understand how E157 can be effectively applied.

First of all, the E157 Module Process State Model is fairly simple, having only 4 states (three of which are “base states” with no sub-states) and 7 state transition events, shown in the diagram below.

This model represents the state of that portion (or portions) of a unit of equipment that executes a recipe to transform whatever material is present in that part of the equipment. In front end equipment, the chambers are relatively distinct, and usually process a small number of substrates (often one) at a time. By contrast, backend processes cover a broad spectrum of material types, from single wafers to strips (or lead frames) of multiple die to individual packages. The material flow characteristics also vary, from discrete (i.e., single workpieces) to batch to continuous. Moreover, the production rates and material volumes for these processes range from perhaps 90 wafers per hour to thousands of packages per hour… With these challenges, it is no wonder that the pace of automation for these facilities has lagged that of the front end.

How is the E157 Standard Used?

From the equipment’s perspective, every time the process module changes state according to the model above, the equipment sends the corresponding state transition event to the factory host computer. This is done using the SECS-II S6, F11 Event Report message with an event name exactly prescribed by the E157 standard.

The event report should also include whatever “context information” from the equipment that the factory applications need to analyze the equipment’s performance and behavior. For some backend processes, this might be lot ID, process job ID, recipe name, control settings, and current parameter values for important process variables. For others, it might be cumulative usage counts for fixtures with limited lifetimes, current levels of consumables used in the process, or configuration parameters for equipment with a range of setup possibilities. To further complicate matters, some of this information is common across most processes, some of it is process-specific, but some of it may actually be vendor-specific. It all depends on how the factory operates.

Finally, when used in conjunction with event timing information from other required standards (e.g., E90 Substrate Management), E157 data can help identify potential productivity issues, say, when there is an unexpected delay between material arrival (from E90) and recipe start (E157).

How Might E157 be Adapted for Backend Equipment?

As noted above, some equipment types process a stream of material continuously. In these situations, for a given lot, multiple substrates may be processed at the same time in a continuous flow (say, on a conveyor through an oven) until the lot is complete. For these types of equipment, E157 cannot be directly applied because it is chamber oriented, and you don’t get much useful information if you use the entire lot as the execution starting and completing events.

However, if you apply the same state model to the material (substrate, strip/lead frame, carrier, etc.) being processed rather than the equipment component, the collection events defined by E157 can be implemented when a unit of that material changes state. Specifically, the equipment can report the same collection events (ExecutionStarted, StepStarted, StepCompleted, ExecutionCompleted, StepFailed and ExecutionFailed) when execution on a substrate changes state, including when a step is started and completed. The meaning of a “step” would still be interpreted and designed by the equipment supplier. Associating these E157 collection events with a new “substrateID” data variable rather than a chamber enables the factory user to track the material state for each substrate going through the equipment.

Which Backend Equipment Types Should Implement E157?

Even though backend metrology, inspection, and test equipment may run recipes to perform their tasks, since no material transformation takes place, the state transition events and related context are far less important than the measurement and inspection results that these equipment types generate.
For the rest of the backend processes, the relative priorities for implementing E157 are the following:

High – die attach, wire bonding, dicing/sawing/singulation

Medium – backside grinding, polishing, plating, annealing molding, trim and form

Low – wafer mounting, die glue curing, deflashing, laser marking, tie bar cut, baking, burn-in

One category of equipment we have not mentioned is custom assembly equipment that can vary greatly by the end product form factor. The use of E157 in this equipment will depend entirely on the process complexity and sources of variability that must be tracked. However, it is safe to assume that for all but the simplest of processes, E157 will likely play a useful role.

Conclusion

E157 is a prime example of an exceptionally simple and well-written standard built on top of GEM technology that is easy to implement and provides a lot of end user value. The SEMI ABFI task force is now evaluating the specific adaptation of E157 for various backend equipment types and welcomes your contribution to that process.

We are once again gearing up for a virtual show next week! SMTA International is going to be held virtually 28-30 September, 2020. We are excited to be exhibiting at this show for the first time! SMTA International (or Surface Mount Technology Association International) was established in 1984 and is a non-profit international association of companies and individuals involved in all aspects of the electronics industry. The association brings together a professional network of process engineers, executives, project managers, designers and technologists who are shaping the future of the electronics assembly industry.

For the first virtual SMTAi Conference, anyone can register for a free expo pass that also includes the Live Electronics Expo, (Mon-Wed 9/28 – 9/30), the Student and Young Professionals Program (Tues PM 9/29), the Women’s Leadership Program (Wed PM 9/20) and much more.

Cimetrix will have a virtual booth that will me manned by product experts throughout the 3-day expo. We will have live demo times available by reservation (you can sign up now or during the show!). We will also have videos and documentation that features our products and services.

Cimetrix Sapience® will be showcased at SMTAi. Sapience is a smart factory platform to seamlessly connect varying factory equipment within a single event-driven framework. The Sapience platform provides rapid-deployment tools for factories to mine the treasure trove of data available from shop floor equipment, driving actionable insights for optimal decision-making.

We would love to “see” you at the virtual SMTAi Conference next week! Be sure to stop by our booth and talk to us! There will be private chat and voice/video conferencing available from 9:30 am – 4:30 pm CT during the expo and we’d love to meet up and talk about your needs!

SEMICON Taiwan 2020 is coming soon and our Taiwan team will be there! You can read about it now in Traditional Chinese or below in English

SEMICON Taiwan將是SEMI的第一個全面的實體虛擬活動。這與Cimetrix的業務完全吻合，我們將在智能製造大廳的K3068號展位展出。

我們知道今年是史無前例的，許多人將無法前往台灣。但是，我們想邀請所有能夠參加展會的人前來參觀，看看Cimetrix的新功能！ （您也可以在演出前隨時與我們安排會議）！

Cimetrix將在SEMICON Taiwan上展示我們的最新產品和尖端技術。這包括我們的設備控制平台演示，EDA產品以及GEM連接性和一致性測試產品。我們還將能夠提供有關SEMI標準和SEMI技術的一些最新更改的更新。

我們也很高興宣布今年的演講嘉賓：我們的新產品創新副總裁艾倫·韋伯（Alan Weber）和我們的台灣總經理李孟修（Michael Lee）將就“半導體智能製造：業務驅動器，技術的不斷發展的紐帶和標準”發表演講。於9月24日星期四上午11:30會見專家展位（J3146）

祝大家安全健康地進行展覽。儘管我們的許多全球團隊都會錯過此次展會，但我們的台灣團隊和合作夥伴將隨時準備回答您的所有問題。我們希望看到你在那裡！

SEMICON Taiwan will be SEMI’s first comprehensive physical-virtual event, and will take place during September 23-25 at TaiNEX 1 (Nangang Exhibition Center) in Taipei, Taiwan with the theme “Leading the Smart Future.” This is perfectly aligned with the business of Cimetrix, and we will exhibit in the Smart Manufacturing hall at booth K3068.

We know this year is unprecedented and many will not be able to travel to Taiwan. However, we would like to invite everyone who is able to attend the show to stop by and see what’s new with Cimetrix! (You can also schedule a meeting with us at any time before the show)!

Cimetrix will showcase our latest products and cutting-edge technologies during SEMICON Taiwan. This includes our equipment control platform demonstrations, EDA products and GEM connectivity and compliance testing products. We will also be able to give updates on some of the latest changes to the SEMI Standards and SEMI technologies.

We are also excited to announce our speaker this year: Alan Weber, our VP of New Product Innovations, and Michael Lee, our General Manager in Taiwan, will speak on the topic of “Semiconductor Smart Manufacturing: An Evolving Nexus of Business Drivers, Technologies, and Standards” at the SEMI Meet the Experts Booth (J3146) on Thursday, September 24 at 11:30 a.m.

We wish everyone a safe and healthy exhibition. While many of our worldwide team will miss being at the show, our Taiwan team and our partners will be available and ready to answer all your questions. We hope to see you there!

Meet Khoi Ha, CCF Services Software Engineer at Cimetrix. Read on to learn a little bit more about Khoi.

How long have you worked at Cimetrix?

I've been at Cimetrix for almost 10 years now (November 2020)!

When did you graduate and what degree did you get?

I graduated from Ecole Polytechnique de Montreal in Montreal Canada in 1990. My degree was in Electrical Engineering.

What drew you to Cimetrix originally?

One of my previous semiconductor companies which I worked for used the Cimetrix CIM300 product so I knew about Cimetrix before I came here. But I was spotted and hired by a previous Director of Engineering.

What is your role at Cimetrix currently?

I am a Software Engineer in the CCF Services Team. 

What do you think it means to a client to have a great CCF services team?

As an engineer for the Services team, we go through the customer requirements and then we must understand and come up with strategies to tackle them. We break the requirements into work items and implement or resolve them one by one. We go through many scenarios of tests for the implemented features. We then consult back with the customers once the features have been implemented correctly and as intended. We make sure that the customer is satisfied with every implementation, and we make sure to deliver on time. In our spare time, we either enhance our documentation or create product trainings.

What do you like best about the work you do right now?

I enjoy helping our customers to be successful by assisting them in building their systems effeciently and on time. 

During my years at Cimetrix, I have been part of different departments (Services, Engineering and Support).  I was involved with CIMConnect, CIM300 and especially in CCF product development.  This extensive product knowledge has helped me tackle challenges when I'm called on to integrate our software with customers equipment.  

What do you like best about working at Cimetrix?

Cimetrix is like a family company. I always feel that people are here to help each other build great products and offer our clients valuable solutions. Every time I've had a challenge getting something done, I was able to rely on other product experts and engineers to help me with the issue and resolve it in a timely way.

What is your favorite vacation spot?

Hawaii or Bora Bora (Well I've never actually been to Bora Bora, but I'm crossing my fingers that one day the company might send me there!)

What do you like to do in your free time?

I am learning to play my guitar, and I always like to play around with my gadgets.

Meet Harry Aldrich, CCF Services Software Engineer at Cimetrix. Read on to learn a little bit more about Harry.

How long have you worked at Cimetrix?

I've been at Cimetrix for just over a year now and I work from Camden, Maine.

When did you graduate and what degree did you get?

I graduated with a BA in Physics from Gordon College in Massachusetts.

What drew you to Cimetrix originally?

I have actually been a happy customer of Cimetrix for close to 15 years, and I enjoyed working with the products and team. I'm excited to now be a part of this company.

What is your role at Cimetrix currently?

I am a Software Engineer on the CCF Services Team.

What do you think it means to a client to have a great CCF services team?

Cimetrix makes great products that are foundational to the successful implementation of equipment for today's factories. Having robust products to rely on is great, and having a company that stands behind those products is even better. 

I have benefited greatly from the experts at Cimetrix in Services and Solutions who have "been there and done that", both from their knowledge of the standards to their expertise in the products that implement them.

What do you like best about the work you do at Cimetrix?

I value the opportunity to work with a number of different customers on a variety of equipment that present new and interesting challenges.

What is something you’ve learned while working at Cimetrix?

I have learned the importance of continuing to learn all the time.

What is one of the hardest challenges you’ve been faced with at Cimetrix and how did you overcome the challenge?

Learning a new platform (CCF) as part of a new team (CCF Services) with new responsibilities are among the challenges I've faced. I think teamwork and coaching have been the most significant things in dealing with these challenges. 

What is your favorite vacation spot?

Tirol, Austria

What do you like to do in your free time?

I am an avid golfer and a big sports fan.

Hi folks! We in the CCF (CIMControlFramework) Services Team love training/consulting on CCF implementations and building custom software for our customers. We’re especially thrilled when we can help our customers ship new equipment and subsequently hear that the equipment successfully ran thousands millions of cycles without issues.

Recently, we enjoyed helping one of our customers build a tool that processes non-wafer substrates. The tool control system included some typical components such as Rorze Hardware Drivers, Light Tower drivers, and a Load Port E84 IO Control, but had some more unique capabilities as well. In this posting we will explore some of the challenges posed and advantages realized from these special capabilities. Before we dive in, please allow me to give a shout out to John Last, our Senior Software Engineer who designed and built most of these capabilities.

Process Module Operation Screen

Rather than simply logging data points, our customer wanted a visual representation of temperature over time (minutes). We displayed the categorized variables and their values in tables as well, but the graph updating in real time made it much easier for the operator to visualize the patterns and identify risk events and their sources. The graphing feature needed to be active whether or not the process module operation screen was being displayed. Moreover, It had to handle 3 different step types (Ramp, Dwell and Cool).

Calculating the Y-Axis range for this display presented an additional interesting challenge. The minimum and maximum values were determined by searching all recipe steps and selecting the lowest and highest value setpoints, then subtracting a fixed number from the lowest to get the Y-Axis minimum value and adding a fixed number to the highest value to get the Y-Axis maximum value. The figure below shows how the expected process data should look compared to the observed process data. This allows the operator to see what the equipment is expected to do compared with its actual behavior.

Partial FOUP grouping to create a single batch

Our customer required the capability to group multiple partial FOUPs into a single batch. This is especially useful in scenarios where partially filled FOUPs would be used—say, in R&D environments. In other words, we needed to support scenarios where the number of FOUPs needed for processing a batch exceeded the number of load ports. This required us to create Control Jobs with a MtrlOutSpec containing a valid SourceMap with an empty DestinationMap. We relied on SEMI E94’s concept of “Late Announcement of Output FOUP” to specify the input FOUP but not the output FOUP. This allows the scheduler to say, “We know the substrate will go to a different slot, but we won’t tell you which slot until later.”

E90 substrate reading in the Panel solution

As with most tools, each of the substrates has an ID, and this ID must be read and reported to the host. In this case, our host had to verify that the expected ID matched the actual ID. On a successful match, the equipment would then continue the job. If it failed, however, the host would be notified and decide whether to proceed or change something. Capabilities like these maximize throughput and mitigate risks to equipment safety side and production scrap.

Different Panel Types

This machine was required to deal with panels having multiple thicknesses and possible warpage. Therefore we needed to provide a method for an operator, the recipe, and the host to specify the panel type to be processed. None of the variations of panel types were known ahead of time, so we needed methods that handled additional panel types without having to make code changes after the equipment was deployed in production.

The tool also required different substrate mapping parameters for each panel type. Because panel type was specified in the process program referenced in the Process Job, the panel type was not known when the FOUP arrived at the load port. To handle this situation, we customized a standard factory automation SECS II message to communicate the panel type from the host to the tool on arrival of the FOUP.

Conclusion

This equipment was built on an extremely aggressive timeline by a very small team. I was particularly impressed by the team’s ability to grasp the end customer’s requests and creatively explore alternative ways to solve the never-before-seen challenges. In summary: no drama; a few delays; even fewer verbal altercations; just a little frustration; only a little scope creep; and most important, a satisfied factory customer. We all cheered when our customer shipped the tool in 2020.

To find out more about CIMControlFramework and our CCF Services team, or to contact us for a demo, click the button below.

Background

The SEMI North America Diagnostic Data Acquisition (DDA) task force is part of the North America Information and Control Committee (I&CC or NA I&CC). This year the meeting that is normally held in conjunction with SEMICON West was held on Tuesday, July 14, 2020, and continued its activities in developing important SEMI standards. As co-leader of the NA DDA task force, I offer this blog as a summary of the current task force activities.

Freeze 3 Status

The primary responsibility of the DDA task force is the suite of Equipment Data Acquisition (EDA) standards, sometimes referred to as “Interface A.” Currently there are two version sets of EDA standards known as “Freeze 1” and “Freeze 2” which are both based on SOAP/XML over HTTP. The current activities are focused on defining the next EDA set (already designated “Freeze 3”) which is based on a binary protocol gRPC over HTTP. This technology, along with a number of other changes, promises to dramatically increase data collection throughput capacity.

Here is what has been completed so far:

Current Ballot Activity

The bulk of the “Freeze 3” work is still under active development. Here is a summary of the ballot activity as of the start of the meeting on Tuesday.

All of the ballots failed and will be reworked for Cycle 7 voting later this year. However, this was not unexpected, and a great of useful feedback was gathered in the process.

Getting Involved

For those interested in participating, it is easy to join SEMI standards activities. Anyone can register at www.semi.org/standardsmembership.

All SEMI task force ballot activities are logged at: http://downloads.semi.org/web/wstdsbal.nsf/TFOFandSNARFsbyCommittee?OpenView&Start=1&Count=1000&ExpandView

After joining the standards activities, anyone can get involved. The task forces post everything on the connected @ SEMI website https://connect.semi.org/home. The North America DDA task force community is called “Diagnostic Data Acquisition Task Force - North America”.

To find out more about the semi standards, or to speak with a standards expert, click the button below: