Company
Letter to the Editor
Possible Improvements to the Garage Door State Design
J. Cleveland
Software Engineer
Fluid Management, Inc.
"I really like the article 'Developing a Controller Using Design Patterns' and specifically the use of the Unified Modeling Language (UML) for embedded systems. I often use this in my own work on embedded and PC based systems.
I really think the 'Garage Door State Machine' is a fantastic one to use because it is one that is very common, well known, and it also provides enough complexity to be a very good example. In looking at 'Figure 1: Garage Door State Machine', I think there are a couple of significant opportunities for improvement:
- Power-On-Reset State
-
Orientation and Layout
a. From my experience, this state is absolutely critical to define for embedded systems and its absence from 'Figure 1: Garage Door State Machine' immediately drew my attention. I often know when this state is missing from the diagram that there are also other states that are generally missed as well. It can also point out that there may be a hardware or design deficiency, as well. In fact, I made up a quick and dirty diagram myself just to see.
a. Again from my experience, it is often to have the model or diagram match the physical system as closely as possible. In this particular instance, I think it is most helpful to actually have the [Open] state at the top of the diagram, which matches the physical state of the door/opener system and in turn have the [Closed] state at the bottom.
Here is the diagram that I created that could offer some improvements:
From this slight modification to the 'Figure 1: Garage Door State Machine', I think that one can now see the potential for the [Unknown] or [Error] state(s), which to me is the true power in creating these design documents. By just doing this as a document, it allows one to create a "solid" or "complete" design before any time is actually spent on the actual development. Again speaking from experience, the costs by not completing the design can often be catastrophic (in terms of the time lost, time and money required to perform the redesign/rework, and the potential failure that actually occurs in the field)."
