Semiconductor Industry News, Trends, and Technology, and SEMI Standards Updates

Semiconductor

Create Device Drivers Using CCF

Posted by Tim Hutchison: Senior Software Engineer

Dec 6, 2016 11:30:00 AM

In 1976, Blue Oyster Cult released their hit song, “Don’t Fear the Reaper”.  In 2000, Saturday Night Live produced a fictitious, but humorous skit around the production of the “Don’t Fear the Reaper” called, “More Cowbell”.  The “More Cowbell” skit put a very light hearted spin on the production of the hit song.   After seeing that skit, I can never hear that song the same way. The cowbell, for as small a piece it plays, is a huge part of the song.

Keep_Calm_Cowbell.jpg

The same can be said for the hardware that is used in Semiconductor manufacturing tools.  Tool control boils down to controlling the hardware. Without controlling the hardware, the UI and factory automation will not amount to much if the robot doesn’t move. Everything from the robot, down to a simple presence sensor on a load port is needed. What may seem to be the simplest device can be the most prominent.  Each device plays an important part in the process. 

A Cimetrix blog post on March 15, 2016 entitled CIMControlFramework Work Breakdown, identifies driver integration as one of the first steps that needs to be done in the work breakdown for a CIMControlFramework (CCF) application. It may seem intimidating to create a driver to control hardware. There is the need to connect to the device. There is some number of commands and possible responses to deal with.  It can be overwhelming, but can be conquered by understanding what needs to be done to control a device through a driver.

Let’s look at how to go about developing a driver.

  1. Understand the interface to the device using any and all documentation available.  The documentation will provide information on how to send commands and interpret the responses.
    1. Does the device control only one device or many?
    2. What is the communication protocol to the device?
      1. TCP/IP
      2. Serial ports
    3. What are the commands?  How are the commands composed?
    4. What are the responses?
    5. Will the device need to be polled?
    6. Will the device send unsolicited messages? 
  2. Understand what needs to be controlled on the device for the tool. 
    1. Will you only need to use a subset of the interface or the entirety of the interface?  If just a subset, then there is only a need to write those initially.
  3. Writing code to “talk” to the device
    1. Do you have a simulator for the device?
      This one is important, especially if the hardware has limited availability.  If needed, a simple simulator can be developed to at least validate communications, then expanded over time to simulate faults or other conditions.

      As the tool begins to come together, each simulator will become invaluable when developing the other parts of the tool and coordinating the devices together. 
    2. Unit tests can be useful to verify that the driver behaves as expected before using on actual hardware.  Unit tests can also provide regression testing should changes be made to a driver.
      Some areas to consider unit testing;
      1. Handling of failure to connect
      2. Handling of failure to send to the device or receive from the device
      3. Handling of return values
    3. Start out simple, just get a connection to the device to begin with.  Next send a simple command and inspect the response.  Create a success and build upon the successes!

In the end, a driver will be sending commands and getting and interpreting a response. For every device you create a driver for you’ll also become the expert on that device.

Even though it can be intimidating to start, developing drivers is one of the fun parts of tool development. There is nothing more exciting than seeing the hardware begin to dance in the fashion that has been choreographed in your software

CCF provides utilities and examples to help create drivers for your hardware and easily integrate them into the application, to assist you to orchestrate and provide more cowbell in your tool control. 

Topics: CIMControlFramework

Leveraging GEM

Posted by David Francis: Director of Product Management

Nov 28, 2016 11:30:00 AM

One of my favorite gifts when I was a kid was an erector set. I could build all kinds of machines and robots. The set I had even included a simple motor, so I could make things move. I spent a lot of hours building machines and robots and dreaming of doing that on a bigger scale.

When I graduated from college I worked for a small company that did warehouse automation and automated transport control systems. It took me back to when I was a boy building robots with my erector set. Except these robots could actually move things and had a full set of commands to control them, not just on or off. The company I worked for had a small group that did firmware programming for the robotic controllers. I worked in the software group that wrote the software systems for controlling the whole automated warehouse. I soon learned that each type of automated equipment had its unique set of commands and that just because two pieces of equipment might perform the same function, didn’t mean they used the same commands.

Along the way I had the opportunity to work with Motorola to develop cell controllers for one of their new, state-of-the-art fabrication facilities in Austin, Texas. This opened up a new world of automation for me. The SEMI Equipment Communication Standards (SECS) were fairly new and still trying to gain wide acceptance. There were a lot of similarities to the automated material handling equipment I had been working with. Each piece of equipment had a defined set of SECS messages it supported, but each tool had to be carefully characterized in order to know how to create the cell control application that would interface with it. It was exciting to bring new tools on line and see the benefits in reduced scrap and improved throughput. But it took a lot of time to develop the cell controllers and there wasn’t much code that could be reused from one to the next.

During this time, I had the opportunity to attend some SEMI standards meetings and participate in discussions about the development of a Generic Equipment Model (GEM) to achieve more consistency across different companies’ SECS interface implementations. It made so much sense! I had built a good business doing equipment characterizations for semiconductor manufacturing companies, but it seemed like there should be a better way of interfacing with the equipment – a more standard way. As the adoption of GEM grew in the semiconductor manufacturing industry, the cost of developing equipment cell control applications decreased. Much of the code could be used across different pieces of equipment, because there was a standard for interfacing with all equipment.

While GEM was developed by and for the semiconductor industry, it could also benefit many other industries. GEM provides a standard way to control a factory and gather equipment and process data that can be used to measure and monitor Overall Equipment Effectiveness (OEE), implement Statistical Process Control (SPC), manage material queues and WIP levels, and a wide range of additional factory applications. Several parallel markets (PV, LED) have adopted the GEM standard to take advantage of commonality required by the standard. Other markets would also benefit by adopting the GEM standard to help increase software reuse and productivity

 

Topics: SECS/GEM

EDA Metadata Conformance Testing

Posted by Derek Lindsey: Product Manager

Nov 15, 2016 11:00:00 AM

In a recent blog posting we introduced the topic of EDA (Equipment Data Acquisition) standards testing and sub-divided the domain into three parts:

  • Compliance testing – does the equipment adhere to the specifications described in the SEMI Standards?

  • Performance and stability testing – does the equipment meet the end users’ performance and availability specifications?

  • Equipment metadata model conformance testing – does the equipment model delivered with the interface represent the tool structure and content anticipated by the end customer?

Today’s post deals with the equipment metadata model conformance testing in greater detail.

The impetus for the metadata conformance requirement is SEMI Standard E164 – Specification for EDA Common Metadata. Although this standard is not part of the original core suite of EDA standards, it is now being required by GLOBALFOUNDRIES and a number of other major semiconductor manufacturers on EDA-enabled equipment.

The purpose of the standard “is to promote commonality among implementations by defining common representations and conventions of equipment metadata based on SEMI E125.” (Section 1.1 of E164)

In other words, conformance to E164 requires a consistent implementation of E125. All state machines required by the GEM300 standards must be implemented and use the same names for required events, parameters, state names and transitions. It requires that all process modules implement the E157 Module Processing state machine using specified names. As a result, E164 ensures a high level of implementation commonality across all equipment types. This commonality enables better automation of data collection processes across the fab, driving major increases in engineering efficiency. In summary, E164 is to EDA what GEM was to SECS-II.

Currently, the only E164 conformance tester is Metadata Conformance Analyzer (MCA) that was commissioned by Sematech and implemented by NIST (National Institute of Standards and Technology). In our discussions with potential users of an EDA test tool, most clients agree that the sooner a replacement can be created for MCA, the happier they will be.

In a previous post, we mentioned that Cimetrix has automated the EDA compliance evaluation procedures. We are also in the process of designing the performance testing components of this tester. The plan is to also create an E164 conformance tester that will replace MCA.

If you want to know more about EDA testing and/or discuss your specific needs or provide input on what you would like to see included for E164 conformance testing, contact Cimetrix for a demonstration of this exciting new capability!

 

Topics: Interface A, EDA

Semicon Europa 2016 is in the books!

Posted by Cimetrix

Nov 10, 2016 11:30:00 AM

SEMICON Europa was held in Grenoble France this year from October 25-27, 2016.  Grenoble is a hot point for semiconductor technology in France with fabs and technology centers located close by.  Typically, this trade fair moves between Dresden and Grenoble each year with attendance of about 6000. 

IMG_4214.jpg

The Cimetrix team consisted of Dave Faulkner, EVP Sales & Marketing; Bruce Febvret, Business Development,  Europe; and Kimberly Daich, our new Marketing Manager.  Cimetrix brought our new double wide booth with new branding and was located next to our integration partner Agileo Automation.  

IMG_3302.jpgWe highlighted our CIMPortal Plus software demonstrating the benefits of the SEMI E164 standard.  Attendance seemed light this year which allowed the Cimetrix team ample time to meet with various equipment supplier customers who had exhibits at the show. Of particular interest to our customers was our advice on when and how to add Interface A to their control systems, and what impact Industry 4.0 and smart manufacturing will bring.  The evening networking event was very well done; congrats to the SEMI team.IMG_3326.jpg

SEMI made an importance announcement that starting next year, SEMICON Europa will no longer move back and forth between Grenoble and Dresden; and will move to Munich in mid-November.  This allows one large show featuring SEMICON and Productronica.  SEMICON Europa will focus on semiconductor related activities and Productronica will focus on electronics assembly technologies.  This decision works very well for Cimetrix as we share customers in both industries. See you next year in Munich!

 

Topics: SEMI, SEMICON

EDA Performance Testing

Posted by Derek Lindsey: Product Manager

Nov 1, 2016 1:00:00 PM

In a recent blog posting we introduced the topic of EDA (Equipment Data Acquisition) standards testing and sub-divided the domain into three parts:

  • Compliance testing – does the equipment adhere to the specifications described in the SEMI Standards?

  • Performance and stability testing – does the equipment meet the end users’ performance and availability specifications?

  • Equipment metadata model conformance testing – does the equipment model delivered with the interface represent the tool structure and content anticipated by the end customer?

    Today’s post deals with the performance and stability testing in greater detail.

In our discussions with EDA users (both OEM implementers and fab end users) about EDA testing, they all acknowledge the need for compliance testing. However, the vast majority have said, “If you can help me automate my performance testing, I would be able to save a huge amount of time.” Most thought they could reduce testing time from several weeks to just a couple of days.

Everyone has different ideas about what should be included in performance testing of their EDA software. Everyone can agree that generally they need to test if the equipment meets the end users’ performance and availability specifications in terms of data sampling intervals, overall data volume transmitted, size and number of DCPs (data collection plans) supported, demands on the computing/network resources, and up-time. They also need to know if the software will support the range of application clients expect in a production environment.

Data Volume

EDA users want to know the sheer volume of data that can be collected.

ISMI has reported in public forums that IC makers expect EDA to achieve data rates of 50+ variables per chamber at rates up to 10 Hz. In EDA specifications, IC makers have requested the ability to gather 1,000 to 2,000 parameters using data collection rates from 5 to 20 Hz, which translates to 40,000 values per second.

These rates are easily achievable with today’s computing platform technology, but users also want to know the upper limit. In other words, at what point does the ability to collect data break down?

Data Quality

EDA users want to know that the data comes in at the specified rates and that the values and timestamps that are received at those rates are accurate.

Resource Usage

EDA users want to know how different data collection rates and volumes will affect the system resources. Will memory usage be too high? How will different collection rates affect CPU usage? Is the network bandwidth sufficient for gathering the required data at the required speeds and still maintain high data quality?

In a previous post, we mentioned that Cimetrix has automated the EDA compliance evaluation procedures. We are also in the process of designing the performance testing components of this tester. The ISMI EDA Evaluation Method discusses some basic performance testing in Appendix B; performing these tests will be included in the feature set of EDA tester now under development. In addition, we are designing ways to help evaluate the data volume, data quality and resource usage of a given equipment.

If you want to know more about EDA testing and/or discuss your specific needs or provide input on what you would like to see included for performance testing, contact Cimetrix for a demonstration of this exciting new capability!

 

Topics: Interface A, EDA

EDA Compliance Testing – Scope and Approach

Posted by Alan Weber: Vice President, New Product Innovations

Oct 19, 2016 11:30:00 AM

In a recent blog posting we introduced the topic of EDA (Equipment Data Acquisition) standards testing and sub-divided the domain into three parts:

  • Compliance testing – does the equipment adhere to the specifications described in the SEMI Standards?

  • Performance and stability testing – does the equipment meet the end users’ performance and availability specifications?

  • Equipment metadata model conformance testing – does the equipment model delivered with the interface represent the tool structure and content anticipated by the end customer?

Today’s post deals with the first of these parts in greater detail.

To begin, we should point out that standards compliance testing is not a new idea – it has been an integral part of the acceptance testing process for automated manufacturing equipment for decades. As each new generation of SEMI’s communications standards (SECS-II, GEM, GEM300, and now EDA / Interface A) reached critical mass, the compliance testing process naturally evolved from an ad hoc, manually driven set of procedures to a more thorough, formal process supported by automated testing software. Moreover, the use of this kind of software and the reliance of leading chip makers on its results has greatly contributed to the efficiency of the overall new fab startup and initial yield ramp process, so its importance to the industry cannot be overstated.

So where does the industry turn for information about how to test for EDA standards compliance?Although the Sematech manufacturing consortium’s R&D program no longer includes SEMI Standards definition, validation, and promotion support, the work that its ISMI subsidiary (International Sematech Manufacturing Initiative) did in the formative years of the EDA standards is still directly applicable. In particular, the “ISMI Equipment Data Acquisition (EDA) Evaluation Method for the July 2010 Standards Freeze Level: Version 1.0” is the globally accepted approach for checking compliance of an equipment’s EDA interface.

 ISMI2.png

This document takes an automation test engineer through the entire set of steps for connecting a tool to a known-compliant test client (in this case, the Cimetrix Equipment Client Connection Emulator, or ECCE Plus product), adding entries to the interface’s Access Control List (ACL), uploading and inspecting the equipment metadata model, managing Data Collection Plans (DCPs), and invoking all the other services defined by the SEMI EDA Standards suite (E120, E125, E132, E134, E164, etc.). Its appendices not only define the required procedures in detail, they also describe the expected results and suggest a format for reporting these to interested stakeholders.

Of course, those familiar with the use of this method and the associated software tools know that it can take 2-3 days to execute this process manually, which is an inefficient way to check compliance for the incoming tool set of an entire fab. Fortunately, there IS a better approach. Cimetrix has automated these evaluation procedures in a way that ensures the target equipment meets the automation software purchasing requirements to the satisfaction of both the equipment supplier and the semiconductor manufacturer, while leaving the door open for factory-specific requirements that represent unique competitive advantage.

Note that ISMI and its member companies also recognized that much of the potential value of the EDA standards would be derived from (and limited by!) the content of the equipment metadata model, so they funded the development of another software tool to check these aspects of a supplier’s implementation. But that is a topic for an upcoming blog – watch for it.

So… if you want to know more about EDA testing and/or discuss your specific needs, contact Cimetrix for a demonstration of this exciting new capability!

Alan Weber
VP, New Product Innovations
Cimetrix Incorporated

Topics: Interface A, EDA

EDA Testing – What Does the Problem Look Like for the Industry?

Posted by Alan Weber: Vice President, New Product Innovations

Oct 4, 2016 11:15:00 AM

Anticipating and promoting the increased adoption of SEMI’s Equipment Data Acquisition (EDA / aka Interface A) standards, we’ve posted a number of blogs over the past 12 months to address questions that potential stakeholders have repeatedly asked across the value chain. These postings have dealt with everything from the factory applications enabled by EDA to the best practices for OEM implementation of these standards to the development of robust equipment purchasing specifications.

Since the 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?” in a way that supports the entire industry. It’s an excellent question, and one that has a multi-part answer.

EDA_Icon.png

Given the structure and expected use of the EDA standards, the acceptance testing process for a unit of semiconductor manufacturing equipment will include at least three components, each of which addresses a different aspect of the standards. Note that we’re explaining this from the perspective of the end customer in a semiconductor factory, since this is the most common use case, but most of the same principles apply when testing EDA client infrastructure/application components as well.

  • Compliance testing – does the equipment adhere to the specifications described in the SEMI Standards, and were these specifications interpreted correctly? Will it cleanly connect to the EDA client infrastructure without modification or extensive configuration?

  • Performance and stability testing – does the equipment meet the end users’ performance and availability specifications in terms of data sampling intervals, overall data volume transmitted, size and number of DCPs (data collection plans) supported, demands on the computing/network resources, up-time, etc.? Will it support the range of application clients expected in a production environment?

  • Equipment metadata model conformance testing – does the equipment model delivered with the interface represent the tool structure and content anticipated by the end customer? If the customer has requested that SEMI E164 (EDA Common Metadata) be fully supported, does the metadata model meet these specifications?

Of course, in addition to the requirements dictated by the standards themselves, most advanced semiconductor manufacturers will have a number of factory-specific requirements that must also be supported by the EDA interface. These may include special events and data for particular automation schemes, vectors of process parameters to support fault detection applications or other feature extraction algorithms, synchronization signals for external sensor integration, and the like. To address these requirements efficiently, an EDA test system should be extensible by its users.

You can see how interesting and vital this topic becomes when you consider the range of requirements outlined above. We’ll explore each of these in more detail in the next few postings, so stay tuned!

 

Topics: Interface A, EDA

Another Exciting Visit to SEMICON Taiwan

Posted by Cimetrix

Sep 27, 2016 10:30:00 AM

01_SEMICON_Taiwan_Exhibition_Center.jpg

Exhibiting at SEMICON Taiwan for the second time in as many years, Cimetrix significantly expanded its presence at the show with a booth in the Smart Manufacturing Pavilion. Like last year, we shared an exhibit with one of our Taiwan partner companies, Flagship International.

02_Booth_in_Smart_Manufacturing_Pavillion.jpg

Since the semiconductor industry is one of the most important economic engines in Taiwan, this year’s Gala Dinner at the Grand Hyatt featured an excellent and supportive speech by the country’s new President, Dr. Ing-Wen Tsai. Taiwan’s tech industries have had a solid year thus far, leading other regions of the world and capturing additional market share.

03_President_of_Taiwan_at_Dinner.jpg

In recent years, SEMI has increased its emphasis on focused “educational” forums at its SEMICON shows, and set a new high-water mark at SEMICON Taiwan with 20 of these events ranging from Design to Materials to Packaging to Overseas Investmen. Cimetrix was privileged to be named as one of the speakers at the Smart Manufacturing Forum, which included presentations by a variety of thought leaders from UMC, Rockwell Automation, ASE, and others. Alan Weber represented Cimetrix with a presentation entitled “Realizing Smart Manufacturing in Semiconductor Industry with SEMI Standards,” making the case that the industry’s factories already embody many of the characteristics of a Smart Manufacturing environment by virtue of the latest generations of SEMI Standards that support the required connectivity and control capabilities.

04_Alan_at_Smart_Manufacturing_Forum.jpg

As a specific example, the UMC “Big Data to Manufacturing Excellence” presentation by Mr. James Lin described the “Wait Time Waste” analysis application, which is directly enabled by the SEMI E168 (Product Time Measurement) standard and the underlying detailed equipment event data called for in the E164 (EDA Common Metadata) standard.

To support the level of ongoing activity at the show and elsewhere in Taiwan, the Cimetrix contingent also included Derek Lindsey and Kerry Iwamoto, shown here during one of quieter moments in the booth.

05_Derek_and_Kerry_in_Booth.jpg

Another highlight of the week for Cimetrix was participation in the eMDC (e-Manufacturing & Design Collaboration Symposium), now in its 10th year in Taiwan. Alan Weber made a presentation entitled “The Role of Models in Semiconductor Smart Manufacturing” that echoed a number of the messages shared at the Smart Manufacturing Forum but with heavier emphasis on the manufacturing applications that are enabled.

06_Weber_eMDC_Cover_Slide.jpg

The basic idea is that most of the information required to support generic process monitoring and calculation of productivity KPIs is now mandated by the latest generation of equipment model standards, and this promises to drastically reduce the factory cost of developing and integrating these applications.
 
On a final note, in discussing the use of the SEMI EDA standards for critical production applications with a number of the leading chip makers during the week, it seems that we are now very close to an industry tipping point for the adoption of this technology. This has been a long time in coming, and opens up a realm of exciting new possibilities for consumers of detailed equipment and process data!

 

Topics: SEMICON

Don’t Miss this Webinar – Industry 4.0, IIoT, and the Semiconductor Industry

Posted by Cimetrix

Sep 20, 2016 1:11:00 PM

Wikipedia graphic putting Industrie 4.0 in historical context (Figure 1)

webinar_image.png

If the attendance at the most recent SEMICON West and SEMICON Taiwan trade shows are any indication, the terms “Smart Manufacturing”, “Industry 4.0” and “IIoT” (Industrial Internet of Things) have indeed gained recognition and momentum as the rallying cry for the 4th industrial revolution (see figure 1).

In order to reach an even broader audience, the folks at Extension Media will host a free Webinar next week (September 27, 2016 at 1:00 p.m. EDT) with the provocative title “Is the Semiconductor Industry Ready for Industry 4.0 and the IIoT?”

Cimetrix’ VP of New Product Innovations, Alan Weber, is one of the presenters, and will make the case that the industry IS in fact ready for Industry 4.0 and the IIoT by virtue of the latest generations of SEMI Standards that support the kind of connectivity and control required by components of a Smart Manufacturing environment. He will not only show how the evolution of these standards has kept pace with the industry’s automation requirements for almost three decades, but also describe a number of concrete factory application examples that directly leverage the model-based aspects of the latest standards to achieve “plug-and-play” status across multiple process areas.

Sharing the agenda for the Webinar is Tom Sonderman, the VP and General Manager of Rudolph Technologies’ Software Business Unit. Tom has over 20 years of direct experience in the world-class Advanced Precision Manufacturing organizations of AMD and GLOBALFOUNDRIES before joining Rudolph, so there are few people in the world more qualified than he to talk about our industry’s automation capabilities.

The link for this webinar was published in Solid State Technology’s September 19 edition of “The Pulse,” but in case you missed it, you can register now by clicking below.

Register Now

This Webinar promises to be an exciting and informative session – don’t miss it!

Topics: Events, SEMICON, IoT

News You Can Use in SEMI Command and Control Standards, Part 2

Posted by Brian Rubow and Alan Weber

May 31, 2016 1:00:00 PM

 172SEMI.pngIn a previous blog we mentioned that two new SEMI standards, E172 and E173, demonstrated that the GEM standard was alive and well and even gaining new momentum by evolving to adopt new technology. The earlier blog focused on E172 with its SEDD files that use an XML schema to describe what is in a GEM interface. Today’s blog is about the E173 Specification for XML SECS-II Message Notation: a new way to log and document GEM/SECS messages, again using an XML schema.

A few years ago Cimetrix was involved in a project prototyping Wait Time Waste concepts and implementation alternatives. This work required Cimetrix engineers to review and extract data from many different SECS-II message log files from a variety of sources, and in the process, exposed a serious weakness in the industry. Because there was no standardized notation for logging SECS-II messages, everyone represented them differently, using different nuances and variations in their notation based loosely on SML (SECS Message Language, which is mentioned in the GEM standard). Additionally, SML itself was designed primarily for human readability, and certainly not for consumption by software programs; moreover, you can’t analyze a long message log without software to do the parsing for you. As a consequence, writing software to review the log files and to extract meaningful data from the log files was far more difficult than it should have been – SML and SML-like notations are simply not suitable for today’s needs. But now there is a suitable, industry-standard alternative. 

At Cimetrix we have utilized various notations for logging SECS-II messages for many years. In order for any notation to be useful it must meet certain criteria. First of all, it has to be easy for software to write (serialize). Secondly, it also needs to be easy for software to read (deserialize). And finally, it should be easy for humans to read and understand.

The original technique we used many years ago was based on the scripting language Tcl (pronounced “tickle”), which uses curly braces as structural delimiters. When programming within the Tcl language, this works very well. In other programming languages, however, it is easy to serialize, but not so easy to deserialize. Another technique Cimetrix had used for a few years was based on XML, which is well supported by all modern programming languages and an integral part of most internet activity. It is very easy to serialize and deserialize. And when formatted with carriage returns and indentation, it is quite easy to read for most humans (at least the ones who are software programmers or web page gurus).

Here is a subjective comparison between the notation alternatives using a scale of 1 to 5 where 5 is excellent and 1 is very poor or difficult.

173_2.png

At Cimetrix we decided to leverage our experience with XML, SECS/GEM standards and the SEMI Standards organization and related communities to develop a notation that everyone in the industry could benefit from. The result was this new standard: SMN. It is comprised of two parts: an XML schema defined specifically for GEM/SECS messaging; and a specification document describing how to use it (although many details of the specification are embedded as annotations within the XML schema file itself). It looks like this:

173_1.png

The schema is found on the SEMI website: http://dom.semi.org/web/wstandards.nsf/complementaryfiles

SMN brings the representation of SECS messages into the Internet era by defining an open, standard, XML-based notation for these messages. So what can you do with this? Here are some ideas:

  • Document individual SECS/GEM messages (the SEMI E172 SEDD file uses SMN for this). You can also document entire message scenarios.

  • Log individual SECS/GEM messages or scenarios in XML format. These can include only the messages, or might also include protocol messages (like the HSMS separate message).

  • Share message logs with others. If their software supports SMN, they can immediately make use of it. This should increase collaboration in the manufacturing community, particularly between equipment suppliers and their customers.

  • Embellish log files with comments and meaningful metadata, like data item names, variable names, collection event names, etc.

  • Analyze and extract information from log files offline for projects like Wait Time Waste, where you don’t need to process a live data stream.

  • Log messages in a raw binary format to save disk space, yet encapsulated in XML for convenience.

  • Many of the numerous XML tools in the software development community can now be used by SECS/GEM software developers. This opens up a world of opportunities.

  • Products like our CIMConnect and CIM300 can make use of SMN to make it easier to implement GEM and GEM300 interfaces on the equipment by using the SECSData element from SMN to pass data from the equipment supplier’s software into our product.

It is exciting to see the GEM standard evolve and embrace new technologies like XML to make integrating manufacturing equipment into the factories easier and easier.

For more information about these latest standards, and how you can incorporate them into your interface implementation, please contact us.

Topics: SEMI Standards, SECS/GEM, SEMI

Receive Email Updates

Follow Us

Learn More About the
SEMI Standards

SECS/GEM

GEM 300

Interface A/EDA

PV2 (PVECI)