One of our jobs (at
SystematicDesigns) was to make an emulation-test environment so we could test our applications without having to actually install it in the factory. So we needed to make equipment emulators. The emulators could be pretty basic - they only needed to emulate the messaging behavior of the equipment, not any of the internal details. We (that is, other members of the company) wrote a few emulators in C and found that it was tedious and time-consuming. Our project leader suggested that we could use a tool provided by our communications software vendor for writing the emulators. For some reason I had a great antipathy to that tool - it felt awkward and limiting. So on Friday afternoon I undertook to write a language that we could use for making emulators. On Tuesday morning it was pretty much functional, and by the next week we were using it for writing emulators. The first time our project leader saw it he said that it needed a debugger. That turned out to be very simple - it only took a day or two to add basic debugging features like breakpoints and variable-value display.
The reason I mention this language (we called it EL-1 - Emulation Language, 1), is that it contained the seeds for the
EventMechanism that I would later design for SPL.
SPL
About then I got hold of Harel's original article on state charts, "A Visual Formalism". Its significance didn't really become apparent to me until a couple years later, unfortunately. At first I saw state charts as simply another kind of design diagram - that is, another way to procrastinate before actually doing something useful. But in 1994 I left the company I was working for (
SystematicDesigns) to go work for another company (
ObjectEngineeringInc), run by a friend of mine. My mission was to do
something that would make it easier for us to design and build station controllers - software for doing remote control and monitoring of semiconductor manufacturing equipment. After a few weeks of dithering and thought experiments I came up with a language based on state charts that we called SPL :
StateProgrammingLanguage.
I left
ObjectEngineeringInc to return to
SystematicDesigns after 16 months. This was during on of the semiconductor downturns, and the original company was weathering the storm better. I started almost immediately designing a new Windows-based
SecsGem package. SECS and GEM are the communication and scenario standards for semiconductor manufacturing equipment. The old package that we had been using was showing its age, and was no longer really marketable. It seemed clear enough that a Windows UI, a flexible object model, and some kind of state modeling would make a compelling package. Unfortunately at that time I believed that the
NotInventedHere syndrome was a Bad Thing. So instead of building state modeling software I undertook to buy one. There was a nice looking product called
BetterState. It featured a graphical front-end for drawing Harel state charts, and a decent code generator. We gave it a try, brought the developer out to our site to talk about a few issues, and decided to go ahead with it.
We soon found, though, that
BetterState was not much to our liking. The graphical UI was clunky, the code generation led to some non-intuitive outcomes, and there was no usable
EventMechanism. We soon dropped
BetterState, and that was really the end of state modeling at our company for quite some time.
SCG
Eventually I became involved in a project that, once again, was based on distributed applications - communicating state machines. We did the first phase of the project - one cell controller, one station controller, and several other applications - without any state-construction tools. The station controller was particularly complex. The equipment did not report material location in a sensible way, recipe management was difficult, and detailed process tracking was impossible under certain conditions - and it was important for us to know when those conditions occurred.
When it came time to do the second phase - 3 additional station controllers, meaning additional complexity in the cell controller, as well as a more sophisticated interface to the MES system - I realized that we needed some kind of tool to make the development easier and more sensible. State charts sprang to mind but I decided that, since I would get no management backing for making a new tool, and would, therefore, have to do it on my own time in and quickly, I should make a simpler tool. So I made a tool for constructing finite state machines, and called it
SCG (
ScenarioCodeGenerator - another of my really snazzy names - should have been in marketing).
Well, that's part of why I made this web. I need to figure out what, if anything, I want to do about state charts in the future.
--
DaleBrayden - 07 Jul 2002
Books RSS
