What is a Behavior Model?

In systems engineering, many practitioners never create a behavior model. They work with requirements, develop plans, perform risk analyses, etc. When modeling, many professionals focus only on the physical models: block diagrams, interface diagrams, etc. Even when they are doing “functional analysis,” we frequently see hierarchy diagrams of the functions, but no functional modeling beyond that. How do we know we have a complete set of functions if we just created a hierarchical list?

This is when behavior modeling enters the picture. Looking through literature and online resources such as the Systems Engineering Body of Knowledge (SEBoK), it’s hard to find a complete definition of what behavioral modeling is in systems engineering, although we use it all the time. A behavior model provides a way to show how different parts of the system interact with each other functionally to perform system tasks or functions. It’s used to determine the steps from an initial state to a final state of the system. It focuses on the functional steps in-between rather than various modes between states, as you would do with a State Transition Diagram. The sequencing of these steps also provides a way to see the impact of information on the path taken by the system. In addition, we can test the behavioral model through simulation of the steps to determine if the process is feasible. If we add time and other factors, we can even better understand how the system will perform.

Different forms of behavioral modeling have been used over the years including Function Flow Block Diagrams (IDEF), Activity Models (SysML), and Action Diagrams (LML). Since LML is new out of all these languages, perhaps it provides the most complete and nuanced form of behavioral modeling, particularly with the extensions provided in Innoslate. The LML Action Diagram from Innoslate is shown below:

The rounded rectangles are the basic Action class entities. The decision points or constructs are special types of Actions (LOOP, OR, SYNCH). A special case of the SYNCH point is provided in the Parallel construct provided. These decision points help determine the path of the steps depending on the decision criteria. Decision points, like basic Actions, can be allocated to whom or what performs them. The green parallelograms represent Input/Output (I/O) entities (data, information, or even physical items exchanged). I/O can act as a “trigger” to affect the timing and sequencing of the Actions (an Action cannot proceed until it receives a trigger). The purple hexagon represents a Resource class entity. Resources can be produced, consumed, or seized by an Action. They represent physical entities, such as fuel, power, and computer memory. The “Branch Asset” enables the user to select a physical object to allocate the Actions. The tool only provides the feature for the Parallel and SYNCH constructs. With these entities, we can model complex processes.

At this point, you may be thinking, “So What… Why should I care?”

These behavioral models enable us to predict the behavior of the system. That behavior does not have to be deterministic since we can add stochastic (random) behavior to the Actions and decision points. By creating a predictive tool early in the design phase, we can test it earlier, find flaws/errors in logic, and more that could cause the system not to perform well or even worse: catastrophically fail, resulting in loss of life. No designer wants to feel responsible for these kinds of failures. We should view behavior modeling as a way to do a better job of systems engineering and as a result, create better products and services for the world.

Looking for a powerful tool to visualize and analyze your systems engineering data? Start making data-driven decisions with Innoslate. Sign up now!