It is generally accepted that with the limited supply and high cost of petroleum-based fuel (gasoline), alternative non-petroleum-based fuels are needed to propel personal transportation vehicles in the years ahead. While much research and development has and continues to be focussed on improving gasoline efficiency, building lighter-weight vehicles, bio-fuel engines, solar energy capture, improved batteries, hybrid gasoline/battery engines, and hydrogen fuel cells, this paper proposes a radically different yet complementary solution to mobile non-rail based vehicle propulsion. Note that the electric propulsion energy-source approach proposed in this article can inter-operate with current and forthcoming techniques for maximizing fuel efficiency in motor vehicle propulsion systems. In summary, this paper proposes:
1. Public (and private) roadways should be retrofitted with a conductive power-transfer mesh that SAFELY supplies electric power to vehicles travelling on the roadway. As an analogy, one may think of this as a ’slot-car’ type mechanism, similar to the ones we played with as children.
2. New automotive vehicles would be designed (or existing vehicles retrofitted) to draw electric power from the roadway as they freely travel, possibly through the tires as they contact the road surface while the vehicle travels.
A key assumption is that there will be readily available and affordable non-petroleum based fuels to effectively and sufficiently energize the United States fixed power grid for the foreseeable future. This seems to be a sensible assumption, with the possible use of more atomic energy, clean coal, natural gas, solar, and other emerging alternative energy sources.
From a historic perspective, internal combustion engine petroleum-based cars were introduced in the late 1800’s and early 1900’s. Prior to that time, existing roadways had been built for horse-drawn wagons, carts, equestrian riders, and foot-traffic. As motorized vehicles were initially introduced and began to proliferate, roadways were re-engineered and improved to accommodate the new internal combustion vehicles which utilized motor driven rubber-encapsulated wheels to propel the vehicles along the roadway. Consider the roadways in modern industrialized countries that exist today compared to those that existed in 1900.
It is likely that if one had approached a typical European or American businessman or investor of the late 1800’s and suggested building the modern roadway system we now have in order to support the emergence of the then relatively new motorized car(t), they would have been viewed as a wild-eyed dreamer, if not entirely crazy. While the suggestions proposed herein will likely meet similar skepticism, it is hoped the one will consider these changes in a historic context.
Now to the primary topic of this article. Roadway surfaces would be re-engineered to contain a mesh of fixed-grid electrical conductors that can supply power (electrical current) to a vehicle as it freely travels along the roadway. New vehicles (cars and trucks) would need to be designed to utilize this road-way power transfer facility. Certain older vehicles might be retrofited to allow utilization of this new power transfer facility. It would also be wise during the transition period when the existing roadways are being retrofitted with the new power transfer grid facility to incorporate a new commercial infrastructure service system, whereby existing fuel service stations and new cars would be mechanically adapted to support a new arrangement of easily transferable battery packs. This would permit an electric car that has drained its batteries below a specified threshold to stop and pay a fee at a fuel station in order to quickly exchange its batteries with fully charged ones. The drained batteries would be left at the station for recharging, and would be passed on to the next customer.
The design of the new cars and trucks would obviously need to be very thoughtfully planned in order to minimize ‘disruption’ to users and other stakeholders, specifically to maximize backward compatibility with existing infrastructure.
The electric power supplied to the vehicle would be used not only to propel the vehicle along that road-way, but would also charge the vehicle’s batteries so that it could travel on non-grid powered roadways as needed.
The mechanism for supplying the electrical current to vehicles must be designed to satisfy at least the following criteria,
(1) The fixed grid power transfer mechanism must not significantly impede a vehicle’s ability to travel freely in any direction or speed, and must not impact the ability of roadways to accommodate legacy vehicles (existing vehicles that do not use the fixed-grid power transfer feature).
(2) The means of tranferring the power from the roadway embedded power grid to the vehicle must be safe (for vehicle occupants, pedestrians, and vehicle and roadway equipment), efficient and effective, and not significantly impeded by either the velocity (over all normal speeds) or route that the vehicle travels over the roadway.
(3) The power transfer mechanism must include a means to permit the power utility to identify the specific vehicle that is receiving the power, thus allowing the power utility company to periodically invoice that customer. Simply put, each vehicle must have something like a unique Ethernet ID that identifies this vehicle distinctly from all other vehicles in existance. This ID would be readable by controllers in the road-embedded power transfer mechanism, as the power was being supplied.
(4) All new vehicles that utilize the power transfer facility must be designed to automatically and normally operate in a hybrid manner so the vehicle may operate seamlessly when travelling upon a roadway that doesn’t support the fixed-grid power transfer mesh (such as private roadways, parking lots, driveways, older less-used roadways, etc. Travelling between power-grid enabled roadways and conventional non-powered roadway segments must be entirely seamless - although an instrument on the vehicle’s dash will provide the vehicle operator a status indication of the instantaneous and recent power-grid transfer parameters, as well as any other useful power-transfer and battery related status information.
The purpose of this article is not to describe solutions to the above engineering issues, although a few ideas are offered in order to spur discussion. Regarding (1), it might be feasible to conduct electrical current from the roadway to the vehicle propulsion system by means of vehicle tires that contain conductive material (embedded conductive material in the road surface tire treads for instance). To accommodate criteria (2), a mechanism must be designed that permits flowing current from the conductor in the roadway via one or more tires on the vehicle in a manner that makes it virtually impossible for someone standing on the roadway or around the vehicle to be (seriously) electrocuted. This is probably one of the most difficult technical problems, but can likely be solved. It might be prudent to reduce the power transfer between a vehicle and the roadway while the vehicle is not moving, thus limiting risks to pedestrians. Note that pedestrians are normally not in close proximity ( < 3″) to and certainly not in direct contact with the tires of a vehicle that is moving on a roadway. Again, these technical details must be resolved appropriately. New roadway operating policies might be considered as well, including restricting pedestrian access to powered roadways. While this constraint would require additional infrastructure changes, including the construction of pedestrian under and over-passes, this approach is common with respect to electric powered train railways, subways, intra-city electric-powered metro systems, etc.
Ultimately decisions must be made regarding long-term costs. Cost models associated with continuing to rely upon gasoline powered vehicles must factor in both the monetary cost of the fuel, the effect to the environment of emissions, as well as the costs related to military engagements (factoring in the resulting loss of life and serious injury to American soldiers) for current as well as future conflicts that result from the need to maintain the reliable transfer of oil out of the Persian Gulf and other volatile regions. This analysis cannot ignore the reality that eventually our adversaries in these volatile regions may gain access to nuclear weapons, further escalating the potential ‘cost’ related to the need to be engaged in these regions due to petroleum imports.
It has been recognized for decades that reusable code modules provide significant benefits to software development projects, in at least two critical areas. Once a reusable library is implemented and debugged, it is immediately available for subsequent projects and therefore eliminates development time. Secondly, an operational library eliminates uncertainly as to its effectiveness and reliability.
A few years ago, FABNexus developed a transportable library that implements a generic fixed-size message-passing mechanism, in the form of a FIFO queue. This library was designed to facilitate message passing between threads and/or processes running on the same computer system. Internally it used shared memory. The application would specify the queue element size in bytes when creating the queue. The specific content of each queue element was managed entirely by the end-point application users. This message-passing library was implemented on both Windows (WIN32) and LINUX. On a subseqeunt project, this library was easily adapted to function identically with programs running on different inter-networked computer systems. This was accomplished by modifying the libary to utilize TCP/IP sockets, although this was hidden from the application programmer (not entirely, since he/she were required to supply an internet address at queue initialization time).
The current implementation of the inter-networked message-passing library assumes homogenous CPU types at both end-points, but can easily be adapted to support heterogenous computer systems with a relatively modest application interface upgrade. The current implementation requires the application to pass a ‘type-less’ byte-buffer for insertion (’Put’) into the queue, and correspondingly a type-less buffer for removal (’Get’) from the queue. To update the message-passing library to support hetergenous processor (CPU) types at each end-point, the application will be required to utilize library-supplied type-specific GetxxItem() and PutxxItem() methods when inserting and extracting byte-ordered numeric (and other values) from the queue buffer element. These insertion routines will mitigate the effect of differing CPU byte-ordering factors (i.e. big-endian and little-endian matters). For example, the library shall provide for the application’s usage a set of routines such as: PutI1Item(),PutI2Item(),PutI4Item(),PutI8Item(),PutF4Item(),PutF8Item(),PutU2Item(),PutU4Item(),PutU8Item(). Similarly, there will be GetI1Item(),GetI2Item(),GetI4Item(),GetI8Item(),GetF4Item(),GetF8Item(),GetU2Item(),GetU4Item(), and GetU8Item() methods.
More will be said about this facility in a subsequent blog submittal.
Cheers,
Jerry W. Rice
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.
We’re on the air. Stay tuned ….
Welcome to your new blog! This is the first post. Edit
or
delete it, then start blogging!