Semiconductor Manufacturing Software Automation Standards - What does the future hold?
This post describes key accomplishments in the history of the world-wide semiconductor industry’s factory automation software and networking standards adoption, discusses some current trends in this area that are quite disruptive, and concludes by exploring future technology transition planning.
Over the past thirty-five years or so semiconductor per-unit product manufacturing has undergone enormous productivity gains. Advances in material and electronic device sciences, device packaging, testing, improved robotic material-handling and cluster-processing technologies have all contributed to this progression. The remarkable and aggressive application of computing technology itself to device design processes, fabrication, and manufacturing control automation has further accelerated advancements.
A semiconductor or flat-panel-display (FPD) factory production-line (FAB) will typically consist of over one-hundred separate large, expensive and highly complex capital-equipments. These will include numerous varieties of metrology and processing tools. To effectively orchestrate this enormously expensive and diverse collection of processing tools the FAB will usually have a Manufacturing Execution system (MES) and one or more factory-control computer systems. The MES system generally tracks and manages the ‘work-in-progress’ (WIP) and associated product accounting functions, while the factory-control systems coordinate the manufacturing equipment interfaces, material-transfer infrastructure, and facility functions/health-monitoring throughout the factory production-line. Crucial to the effectiveness of these control-systems are the inter-networking (data communication) requirements.
Since a FAB’s manufacturing processing machines are quite expensive, and are built and supplied by separate competitive companies world-wide, from the perspective of the factory’s management organization it is highly desirable that all processing tool vendors provide interoperable industry-standard network messaging protocol interfaces. The goal is to permit the different tools to effectively communicate “out-of-the-box” with no or minimal custom software changes to the factory’s control-system when installed and integrated. Even under the best of circumstances this goal is difficult to achieve, but an industry-standard protocol interface is an essential requirement.
An industry-standard networking interface also facilitates maximum utilization of the equipment with minimal human interaction during automatic production runs. These factors as well as others (such as MTBF of the tool) contribute to the equipment’s ‘cost-of-ownership’ (COO) metric. A lower COO value is desirable, and can weigh significantly in purchase decisions.
Within an operational FAB production-line there are many complex processing and measurement procedures occurring simultaneously across multiple separate equipment platforms. With the overall volume of wafers and devices per wafer involved, it can be quite challenging to avoid, and in some cases to even detect subtle but critical manufacturing variations. Unwanted variations in the manufacturing process should be detected at the earliest possible juncture, to minimize wasted processing resources. Otherwise, the potential for substantial quantities of substrates (each containing many potential devices) being scrapped or reworked is a very costly/painful possibility. In addition to unwanted process variation, factory equipment processing malfunctions must be promptly and intelligently reported, handled, and recovered from in a predictable and systematic manner. Unfortunately, different tool model’s (sometimes even those from the same vendor) are commonly deficient in the manner that their embedded software behaves regarding the myriad of complex exception cases that may arise. While industry standards (SEMI) have been developed to define most common behaviors exhibited by most semiconductor manufacturing tools, error handling and recovery is one of the most challenging and difficult to specify and implement. The SEMI GEM (E30) standard is undoubtedly the most successful software Standard fielded industry wide to date that addresses these issues, albeit in a somewhat general manner (Alarm-State-Model, Process-State-Machine Model, etc).
In a typical semiconductor factory (FAB) there are typically many overlapping processing sequences and correspondingly large volumes of critical metrology and equipment process status values (chemistry, pressures, temperatures, material handling states, electrical and spectral measurements, etc.) generated in real-time across many similar and different equipments. It is essential that each equipment and processing tool in the factory efficiently and reliably communicate relevant data and event sequences to a factory monitoring system via its network connections. Not to be minimized, the factory control and monitoring software must be able to make sense and appropriately interpret and understand these real-time events, data, alarms, and material tracking messages. All things considered, this is a non-trivial collection of activities.
The necessity for industry-wide agreement regarding the specification of and the use of open and vendor-independent network standards has been well understood and addressed for over three decades. It was in the late 1970s when the SEMI user community developed, and eventually published (1982) the SECS-I (SEMI E4) and SECS-II (SEMI E5) data network protocol standards. The SEMI SECS-I communications standard is based upon and uses the EIA RS-232 signal cable interconnect, which at that time was common on most computers, was relatively inexpensive, and easy to work with. SECS-I provides configurable data transfer options, with automatic error-checking and built-in retry capability.
By the early 1990s, high-speed Ethernet using the ubiquitous and reliable TCP/IP protocol was available on many computers, and offered much greater bandwidth at cost only slightly greater than that of RS-232. In 1995 the High Speed Messaging Service or HSMS (SEMI E37) standard was published by the SEMI community, based upon the prevalent TCP/IP technology. Due to bandwidth and transmission distance constraints inherent in RS-232, the newer TCP/IP–based High Speed Message Service (HSMS-E37) has all but replaced SECS-I except on the lowest-end equipment types.
The associated data-presentation layer protocol, SECS-II, defines a platform/operating system independent mechanism for transferring numeric, string, and structured data values across a network of heterogeneous factory equipment and host computers. SECS-II defines standard numeric byte-ordering, with various sized integer and floating-point formats, using a binary-encoding mechanism that efficiently embeds a data item’s data-type, data-set length, and data values concisely into the network message bit-stream. SECS-II very effectively supports the handling and transfer of large arrays (up to 16,777,215 array entries) of numeric and other data items with minimal overhead, which is crucial for most metrology, inspection, and prober equipments which require or generate massive data-sets. Furthermore, as in-situ metrology becomes more common on many processing equipments, this requirement for efficient data handling of large data-sets increases in importance.
Up until 1992, most semiconductor manufacturing tools used various ad-hoc combinations of SECS-II E5 messages to perform commonly needed automation and data transfer transactions. While the SEMI E5 standard gave some guidance as to how various SECS messages (via Stream/Function codes) should be used, there was not a industry accepted overall message standard that imposed a uniform structure as to which specific E5 messages should and should not be used in a given circumstance. As significant an improvement as HSMS, the Generic Equipment Model (GEM-E30) was first published in 1992 to address this need. GEM was an extremely valuable development, since it provided a substantially more complete and conformant framework for designing factory equipment interfaces across a wide-range of equipment types.
A well-designed and implemented GEM/SEM implementation (Specific Equipment Model) provided a relatively easy to manage equipment network interface. The GEM Specification quite thoroughly defines the recommended and permissible (E5) SECS-II message scenarios to be used across all common and recommended equipment automation activities. GEM specifies a fundamental common controller framework comprised of well-defined mandatory state machines and message scenarios that to a large extent allow a factory host computer (with adequate tool configuration database knowledge) to connect-to and perform recipe control and data collection across a wide-range of disparate equipment types, with very little to moderate amounts of host software customization required.
While not diminishing the GEM standard’s usefulness, a notable omission and shortcoming is the lack of a universal interface self-description (i.e. plug-and-play) capability. A self-description capability will allow the factory host computer to query an arbitrary equipment interface via a standard message sequence and thereby determine that equipment’s capabilities and database structure, greatly simplifying the addition of new or different equipments into a given production-line. Other omissions or limitations of GEM are (a) it is constrained to support only a single host or client at a time, and (b) it doesn’t address the issue of network security.
By the early 1990s, software engineering organizations world-wide had fully embraced the practice of object-oriented design and development. The SEMI-user community acknowledged this shift to object-focused design by crafting and publishing a new set of E5-based message standards, specifically E39, that supported distributed remote object transfer and control communications. SEMI E39 and its related message standards were evolutionary in the sense that they were based on the original underlying E5/SECS-II message formats. While these object communications standards are technically interesting, they for a period of time saw little usage in the industry, in part because they added additional complexity with minimally perceived return on investment.
In the later half of the 1990s the industry began in earnest the transition from 200mm to 300mm silicon wafer processing. With the increase in material size and weight, it was no longer safe or feasible for human operators to manually transfer (by hand) carriers of wafers between stations without mechanical assistance. With this motivation among others, the “300mm” material movement and job control related SEMI (E87) standards were developed and published. The new “300mm” material handling related standards also embraced the earlier approach of using object-oriented messaging features that were originally introduced with E39.
From the earliest SEMI software/communication standards published in 1982 through the introduction of the 300mm related standards in 1999, all-in-all there was a relatively balanced technical and industrial engineering emphasis on ‘backwards-compatibility’, technology migration issues, and scalable support for a wide-range of equipment capabilities when considering new automation standards.
Around the turn of the recent Millenium some new concepts in the automation network standards area were being explored and developed. It might be noted that this was in the general time period associated with the explosive growth of the world-wide web/internet within the commercial community. In 2003 a new set of standards referred to as “Interface-A” were published, consisting of E120, E125, E132, and E134. These standards embrace the E39 object-oriented approach, but are revolutionary in the sense that they are based upon an entirely different data-representation and underlying network protocols. Interface-A adopts the commercially prevalent “XML” data markup language for data representation instead of SECS-II, and opts for the internet-oriented “SOAP” protocol instead of HSMS.
The Interface-A standard, while replacing the underlying network protocol and data representation (no longer using E5), adds multiple client capability, interface self-description, internet inter-operability, and attempts to address network security.
Interestingly, the current Interface-A standard is a read-only capable data-collection interface, and in its current specification continues to require an associated E5-based GEM equipment (and factory host) interface that performs all control-related execution operations. Some industry veterans have speculated that the GEM and the 300mm interface standards will eventually be phased-out and replaced with an improved, expanded Interface-A variant. This author hasn’t seen a comprehensive industry ‘road-map’ document that clarifies this issue.
Regarding the industry’s plans in this area, two conclusions seem plausible. Either the Interface-A networking technology will eventually replace the SECS-II and HSMS protocols altogether, or they will forever co-exist. In either case, it appears that there may be a period of many years in which both networking technologies will be fielded side-by-side throughout the industry, resulting in substantial re-engineering costs as well as unknown technical complexity and risks.
Statements have been made at past SEMI meetings indicating that the Interface-A standards might be extended or upgraded using E5 sub-protocols (complementing the XML and SOAP messaging approach). On the surface this doesn’t seem desirable or plausible for a variety of reasons. This would substantially increase the implementation complexity and scope, while proliferating a variety of different protocols which almost certainly results in a wider divergence in messaging. This idea appears problematic since the desired goal is a vendor inter-operable network standard.
The author, both a technologist and business manager, has serious concerns regarding the complexity and risk associated with managing the existing GEM/SECS-II and 300mm interfaces, as well as implementing and supporting the new Interface-A protocol interface on the equipment and corresponding factory host system. This approach results in excessive scope-complexity, planning uncertainty, and on the software-side introduces a multitude of timing or “race-condition” issues associated with correlating related messages traversing in near parallel time-frames over the two separate network paths. In a typical implementation it is almost certain that there will be Interface-A messages and data items that will duplicate those in the GEM interface.
Since the early to mid-1980s the semiconductor manufacturing industry world-wide (both device manufacturers and capital equipment-suppliers) has invested a substantial amount of capital (including many man-years of software engineering effort) into SECS-II and GEM interface development, most of which remains in use today. As significant as the past capital investment, is the overall engineering effort and risk involved in re-engineering and/or replacing the established interfaces with the new Interface-A feature. The scope of this effort is difficult to calculate, but is no doubt substantial. While it is obvious that there are advantages to replacing old technology with new, it might be prudent to consider a less revolutionary approach.
Statements in recent industry trade journal articles have asserted that the legacy SEMI networking protocols are difficult to use and few experts are available that understand them, whereas Interface-A is based upon XML/SOAP protocols which is more ‘open’, easier to use, with more specialists available that understand them. While these anecdotal assertions might have some validity, the semiconductor fabrication industry cannot be equated with the commercial internet in its operational requirements. It isn’t clear that discarding an existing fielded technology and migrating to a substantially different one (which is itself complex) will result in overall improvement. The semiconductor fabrication industry in practice involves domain-specific knowledge that is learned through practical experience and industry-specific training.
It appears that the objective improvements provided by Interface-A are fundamentally
1. Flexible and modern data representation and organization (XML),
2. A universal interface self-description capability,
3. Multiple clients/readers per equipment interface,
4. Internet interoperability, and
5. Network security.
With careful planning most if not all of these desired improvements can in fact be realized by revising and enhancing the GEM-E30 and 300mm standards, using the established SECS-II framework.
It should be noted that the SOAP protocol introduced with Interface-A is in fact using the same underlying TCP/IP network protocol as the already in-place HSMS (E37) protocol. Some authors have reported that Interface-A supports increased data transfer compared to legacy SECS-II and GEM implementations. This can be misleading. Over the same bandwidth TCP connection, SECS-II with HSMS is considerably more efficient than SOAP/XML when transferring large numeric datasets. As previously mentioned, large numeric data-sets are common when dealing with in-situ process metrology and APC feed-back systems.
One promoted benefit of Interface-A is global internet inter-operability offered by the underlying SOAP protocol. Nevertheless, it should not be overlooked that most semiconductor manufacturing facilities are strictly and tightly controlled regarding external data transfer. The possibility of accessing a factory equipment interface over a wide-area network from outside the manufacturing facility certainly offers some benefits, but it isn’t clear that this capability will in fact see wide-use due to prevailing and long-standing operational policies. As previously discussed, the question arises whether this internet accessibility benefit outweighs the disruption and re-engineering costs incurred by discarding the existing network infrastructure.
The author’s organization is currently investigating an internet-based (IP) tunneling protocol technology that will support the transfer of existing equipment and host originated HSMS SECS-II messages over a contemporary internet connection. With appropriate network and application drivers at each end-point and a suitable VPN facility this approach might offer remote-access benefits similar to Interface-A SOAP, but without significantly disrupting the existing infrastructure.
With regard to multiple client readers per equipment interface, it would be prudent to consider extending the GEM standard to support the use of HSMS-GS. With careful thought and planning, this would facilitate a similar multi-client capability as that provided with Interface-A. The HSMS (E37) standard clearly states that multiple client sockets and even multiple parallel sessions are allowed, although not required. The GEM control model state-machine will need to be extended to allow a single REMOTE (control) client, and multiple LOCAL reader clients. One or more additional GEM standard remote commands can be defined that support a safe transfer or hand-off of the remote operator client to another (so that only is in control at a given time).
<Insert self-description paragraph>
Regarding the use of XML data representation, I suggest that it would be less disruptive to extend the existing GEM and SECS-II related specifications to provide as appropriate ASCII (or UNI-CODE) formatted Status, Data, and Equipment Constant (SV, DV, EC) variables that store specialized XML-formatted text for a particular purpose. These data variables could store XML formatted text information that are useful to the needs of the equipment and host users. Since the E37 HSMS standard supports ASCII data items up to 7,995,148 characters in length, this approach would no doubt satisfy most practical application or system needs.
No different than Interface-A, both the equipment and factory host application systems will obviously need to utilize clearly documented XML formatting and semantic rules to construct and interpret the specific XML data involved. In fact, specific equipment variables could be defined to contain XML schema data for control of other XML information in the same system. The possibilities are extensive. The practical uses of XML data across the interface would require concrete definition, clarification, and user community agreement per the standards process.
While the issue of network security is not the author’s area of expertise, I have no doubt that with clearly defined security requirements, suitable solutions of an evolutionary nature can be adapted or developed.
It must unfortunately be mentioned that there have been in the past several SEMI software and network standards published which never gained industry-wide usage, and which were eventually discarded. Specific examples of these were the MESC protocol associated with cluster-tool development, and the SMS standard.
Ultimately business and economic factors, in-part influenced by the underlying technical complexity, will resolve this discussion. What will emerge when the dust settles, one can only conjecture.
April 15th, 2009 at 1:30 pm Excellent site, It was pleasant to me.
April 25th, 2009 at 7:09 am thanks !! very helpful post!