Industry News, Trends and Technology, and Standards Updates

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

 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: Industry Standards, SECS/GEM, Semiconductor Industry

Posted by Brian Rubow and Alan Weber on May 31, 2016 1:00:00 PM
Find me on: