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
