>That's because I worked with the actual lift controllers. They have TONS of additional states, like "door jammed". Or "elevator takes too long to move between

>That's because I worked with the actual lift controllers. They have TONS of additional states, like "door jammed". Or "elevator takes too long to move between floors", or "failed to transition to high speed from low speed", etc. Literally dozens of states with their own conditions and state machines. I feel your pain, I really do - the next step from oversimplification is "how hard could it be", right? (see my comment here https://news.ycombinator.com/item?id=33263261 https://news.ycombinator.com/item?id=33263261 where the responses mostly misunderstand me completely) Just about every state machine example that models a simplified embedded application suffers from the same issue, though. It's not unique to Drakon. I haven't used the full Harel statechart formalism or modeling tools in production, though I expect I eventually will, but I've worked on a project whose state table got about that big before it shipped. Yes, some hierarchy would help a lot. Next time. No, I wouldn't reach for a flowchart representation of a state machine as a first step in anything I can see myself doing. But even though flowcharts for programming pretty much went out with goto, they're still used to represent things like business processes and manufacturing processes (see Six Sigma, ISO 9001, etc). You will find a surprising number of non-programmer stakeholders that are comfortable with them. So I could see it being handy having the approach shown in that link in my back pocket in a bunch of cross-functional ways.