Reuse is a State(flow) of mind…

I’ve written multiple posts on when and why you should reuse software components. Today I want to look at the specific use case of reusable Stateflow Atomic States.

Simple example

The most common example of reusable states I have worked with involves fault detection and management. In this simple example we start off with “NineOclock” and “all = well.” Based on an input “errorCon” we can move to “all = soSo” and finally, if we don’t recover, “all = endsWell.” In this example the transition conditions are inputs to the system (e.g., we are calculating the value of “errorCon” and “recCon” outside of the system. This works for simple examples, but what if the condition logic is more complex? What should we do then?

Parametrized Transitions!

The answer is the use of parameterized function calls. In this example the function “errorCheck” takes 3 arguments, inst, arg1, and arg2. The argument “inst” controls which branch of the switch/case function is used to calculate the transition logic. (Note: you do not need to use all of the input arguments for any given case, however they all must be passed in).

Reuse is still reuse…

Reuse with Stateflow charts has the same limitation of any other reusable function; e.g., the data types for the inputs / parameters need to be consistent across each instance of the chart. Additionally if you want to use the function based method for transition, the MATLAB functions need to be set as globally visible.

Finally, while global data can be used between instances of the chart, since it can be written to in multiple locations, care should be taken that the information is not overwritten. The most common solution to this issue is to use “bitand” functions to turn on or off bits.

Know your history: The Stateflow block

The history junction block in Stateflow™ is a simple, powerful, and often misunderstood entity.  In this blog post, I will try to explain the use of the history junction, through a, hopefully, humorous example.

The Model

For this example, I have coded two versions of the same model, one with the history block and one without.  By doing so I can illustrate the effect of the block.

HistoryJunction

In this example, the first state is the “MortgageStatus”; it has three substates, start of loan, paying off loan and you own your home.  If all progresses normally you will be in the final state after 30 iterations of the chart.

However, there is a second top level state, “BankFraudOccured.”  For this model, I have this configured to be true every 10th cycle.  So let’s look at the results with and without the history junction.

The results

The function of the history junction is to allow users to return to the last active substate within a super state; without it, the user returns to the default substate.  If we look at the two graphs we will see the effect of history junction.

mortgageResults

In the left-hand graph, the instance with the History Junction, the effect of the “bank fraud event” does not impact the payoff of the mortgage.  However, in the right-hand graph, the bank fraud “resets” the mortgage to the “NEW” state and keeps the lender paying off indefinitely.   This can be clearly seen by looking at the Sequence Viewer.

sequenceMortgage.png

The red boxes her show where the model transitions to and from “BankFraud.”  With the history junction in place, you go right back to paying.  Without you follow the default junction to the starting substate.

Words of caution

So in this first example, we had a just a single state connected to our main state. Now let us take a look at a multi-state example

refi.png

In this example, the History Junction would resultmonopoly

in the state returning to “Paying Off” without going through the “Start of Loan” state.   The history junction applies to all transitions into and out of the parent state.   To correct for this the “Refinance State” needs to be to be “Start of Loan” state

refiRight.png

Final thoughts

The first iteration of MAAB style guidelines recommended against the use of the history junction.  With version 2.0 this recommendation was removed and it opened up new modeling patterns for our end users.  Use of the history junction enables multiple design patterns that are difficult to create without it.  Hopefully, this post sheds some light on its proper use.