DEV Community

loading...

Discussion on: Kissing the state machine goodbye

Collapse
anythingwithawire profile image
anythingwithawire

Been doing state machines for years, as a means to create predictable and known behaviours for industrial equipment, from the very large to the very small.

There is a definite skill to system and sub-system decomposition, especially to avoid the state explosion.

Usually then you go to a hierarchial set of state machines, and sometimes you need synthetic machines as intermediaries.

From experience, Uml is the problem, not the answer. Best to use a state table to force consideration of every possible transition. That way you get exhaustive and unambiguous definition of behaviour, with encapsulated transition definitions and if you need event/alarms logging you get first up and masking for free built in.

Plus not hard to train the process owner how to read state tables and then they are the common shared language between them and the implementer, plus the implementer only has to worry about system issues, not interpret some crazy narrative.

I use it that much I wrote myself a simulator with a nice Qt GUI and a bunch of functionality like change journalling, definition documentation for each transition, test all possible combos, OPC server built in to allow simulation, user training, interfacing/HMI etc and then generate code for direct import to end device (embedded or industrial controller).

Then the spec is the product and you have direct traceability back to how/why, requirement of some standards and clients to high levels of rigour.

State machines are well worth the up front effort to get comfortable with, nothing else compares (maybe formal methods, but big entry hurdle) when you need to know/predict exact behaviour of a system.