Modeling Change with StateMachines

Our world is in constant flux as 'things' change or evolve, passing from one state to another. Water freezes, glaciers deform and flow, ice melts, traffic lights cycle between green, amber and red, aircraft take off, climb, cruise, descend and land. The SysML StateMachine is used to describe how structure, in the form of Blocks, changes its state in a time-boxed life cycle. Our concern is not with the structure of the Block Instance but its behavior, which can in turn impact its structure. We are not interested in every single state a 'thing' can be in but rather the significant states. So the important states for water molecules could be a solid, liquid or gas but we are not normally interested in liquid water at a temperature of 67 degrees Centigrade. If we were looking at a movie reel of an object's life time, a StateMachine would pick out the significant frames where important and relevant changes occurred.

Deciding what is relevant is the prerogative and privilege of the modeling engineer, and the same Block could have any number of StateMachines defined by the same or different engineers. An aircraft's state could be modeled from the perspective of passenger embarkation and disembarkation, from the perspective of its maintenance schedule, from the perspective of lift, or any number of other perspectives.

This StateMachine diagram describes the operational states of an SUV motor vehicle. The diagram uses Composite States, which nest States inside other States. There are three high level States - Off, Operate, and the unnamed End State. The Operate State has a number of sub-states, namely Idle, Accelerating/Cruising and Braking. Together with the transitions this describes the states of the vehicle as it Starts, Accelerates, Breaks, Stops and finally when the ignition is turned off.

Using Enterprise Architect an engineer can create StateMachines and define the transitions from one state to another, including Events that trigger state change and Actions that are fired. In addition to these standard modeling representations, the tool has a range of features that can help to visualize and reason about this important linguistic mechanism that ties structure and behavior together. One of these facilities - which we will look at in this topic - is Executable StateMachines, available from the Simulate ribbon.

StateMachines can be defined at any level of granularity as they are an expression of a Block's behavior. Many newcomers to SysML are confused about this point. Because a Block can represent something very simple - such as a switch on a submarine control panel - or something complex like the submarine itself, so too can a StateMachine represent the states of both the switch and the submarine. The two StateMachine models could have the same complexity, even though the things being modeled are themselves clearly at either end of the spectrum when it comes to complexity.

StateMachine diagrams can appear quite simplistic to the inexperienced modeler, but they are highly effective tools for the description and analysis of complex problems that cannot be solved in other ways. It takes a different mindset and approach, and often the kernel of the problem is focused on the selection of the level of Block, its context and the perspective for the StateMachine, rather than the details of the diagram. Often the best results are achieved heuristically by a number of engineers working together. This can be accomplished using Enterprise Architect's collaboration features, allowing engineers dispersed geographically to communicate within the model, either by mail, discussions, chats and formal reviews via the desktop client, or in a Browser on a Smart Phone, Tablet or Notebook.

The StateMachine has its origin in discrete event-driven Behaviors, using a finite StateMachine based on an object-oriented variant of David Harel’s StateCharts formalism.