In the past few months I’ve been writing about how to model basic SysML concepts of behavior using GENESYS. SysML has three largely separate approaches for modeling behavior: activities, interactions, and states. I’ve covered the modeling of behavior using activities and interactions in August (Modeling SysML Activities in GENESYS) and September (Modeling SysML Interactions in GENESYS). This month, I’ll be writing about how behavior is modeled using states in GENESYS.
State modeling, in my experience, has given many organizations significant trouble when attempting to depict system behavior. The difficulty lies in the origins of the terminology. Those with a background in computer science or computational mathematics will recognize the term state from the concepts of finite state automata. Others will simply identify the term with its English definition. Complicating matters more is the term mode, which has a similar English definition and no corollary in finite state automata theory.
Some Definitions
A state is defined generally as: “a particular condition that someone or something is in at a specific time.” The notion of time is important. With this definition a state can be viewed as a particular condition at a snapshot in time. The state is defined by what configuration is in effect at that moment. That can mean the configuration of bits in RAM, or the configuration of bits in the CPU, or more generally, we can identify states by whether the user is logged on or off, or whether the elevator door is open or closed.
A mode is defined as: “a way or manner in which something occurs or is experienced, expressed, or done,” or “a way or manner in which something occurs or is experienced, expressed, or done,” or still “a particular functioning arrangement or condition.” While a state is a snapshot, according to these definitions, a mode speaks more to a categorization of a certain set of available behaviors. Modes define boundaries for certain allowed behaviors.
So, given the loose definitions, how should systems engineers deal with states (and modes)? I’ll first describe how states are modeled in SysML, and then discuss how states and modes are modeled in GENESYS.
States and State Machines in SysML
States, or more accurately, state machines, are one of the three ways that SysML models behavior. SysML avoids the semantic differences between the terms state and mode and focuses on the former term. A state machine consists of a set of states representing a snapshot of behavior at given points in time and the allowable transitions between states. State machines are modeled using a state machine diagram and make use of flow constructs called pseudostates that represent starting and ending points.
Transitions defined between states can depend on a logical expression, called a guard, that must validate true for the transition to occur. When transitions activate, they may also activate certain transition effects, modeled as standalone activities, that are executed during the transition. SysML also supports the notion of composite states, that allows you to model a hierarchy of states and sub-states and allows an entity to be in multiple states at the same time.
States and Modes in GENESYS
GENESYS allows for both concepts of state and mode, providing flexibility to the systems engineer as required. In GENESYS, states as well as modes each have their own class within the systems metamodel. As depicted in Figure 1, using the “decomposed by” relationship, you can model a hierarchy of states and sub-states. States can be related to Modes via the “encompassed by/encompasses” relationship. States are “entered by” or “exited by” a Transition. Transitions are “triggered by” Events that are associated with Items with the “responsible for/assigned to” relationship. A transition can also be related to a Function with the “incorporates/incorporated by” relationship.
Figure 1. Systems Metamodel for States and Modes
As an example of how to model states in GENESYS, consider the example in Figure 2. As shown in Figure 2, the system in question can be in one of three states: Off, Standby, or Engaged. Within the Standby state, there are two defined sub-states, Uninitialized and Initialized.
Figure 2. States and Sub-States
GENESYS also has a state transition diagram to depict transitions between states. As depicted in Figure 2, the Off State transitions to the Standby State when the Power Switch Event is triggered and the Guard condition is valid. The guard logic is defined as an attribute of the transition entity, while the event is tied to the transition via the “triggered by” relationship.
Figure 3. State Transition Diagram in GENESYS
While states in SysML represent a snapshot of behavior at a given time, states in GENESYS can also be defined more broadly to represent any set of system behavior defined by functions. In fact, the flow control of behavior in GENESYS is always defined using a functional flow. States may then be associated with functionality with the “incorporates” relationship.
Consider the notional functional flow for our system as shown in Figure 4. Figure 4 defines a set of functional behavior for the system that completely models the desired behavior of the system. Color coding in Figure 3 emphasizes which functions are associated with which state. For example, while in the Standby state, the system boots software, enables an environment that enables a GUI, and allows users to examine logs, the system while in the Standby state also disables behavior valid for the engaged state.
Figure 4. System Functional Flow and Mappings to System States
In GENESYS, modes are an overarching concept that allows for another means for grouping state behavior. In my experience, modes can be effective when aligned with desired operational behavior, while states are best when aligned with desired system behavior. It is then possible to associate valid states with a particular mode using the “encompasses/encompassed by” relationship. A system may have an Operating mode, and that mode may be aligned with states such as Monitoring or Observing. The full set of relationships for a given state may be viewed using the hierarchy diagram or a hierarchy definition query set to the relationships shown in Figure 5.
Figure 5. Hierarchical View of State-Transition-Event-Item Mapping
Summary
In SysML, there are three independent ways of modeling behavior. Each method comes with its own vocabulary and rule set for diagrams. In GENESYS, we use the functional decomposition to drive the display of sequence diagrams, and we associate the functional model with the states, modes, events, and transitions shown in state transition diagrams. In this way, you only model behavior once to cover all three aspects of behavior, saving you time, inconsistency, and headaches.
