8. Model Architecture Explanation
This section provides a high-level overview of model architecture that is suitable for model-based
development without specifying specific rules.
Roles of Simulink and Stateflow
When using Stateflow, Simulink is required for inputs, outputs, and structuring. Stateflow alone can
perform a variety of formula processing. When using Simulink, complex state variables can be realized
through methods such as [Switch Case].
Either Simulink or Stateflow can be used to model specific parts of control, however, the application of
either product in the development workflow is based on the user’s understanding of the underlying
algorithms and, ultimately, comes down to the organization to determine which tool is best suited for their
needs. Determining whether Simulink or Stateflow should be used for design should be determined by a
group of people in accordance with the task. Whether implementation in Stateflow is done by using state
transitions or with flow charts should also be specified.
In most cases, Stateflow is less efficient with regards to RAM. Therefore, Simulink has an advantage in
computations that use simple formulas. In addition, Simulink is more advantageous for situations where
state variables are operated with simple flip-flops and [Relay]. When evaluating whether to use Simulink
or Stateflow in a project, these topics should be taken into consideration:
• Increasing RAM: There must always be a RAM available for visualization of Stateflow inputs, outputs
and internal variables.
• Equation error handling: When general computational formulas are used internally, the user designs
ways to prevent overflow.
• Splitting and separating functions: When performing calculations that use Simulink outside of
Stateflow, there is a possibility that they may split, thus reducing readability. There are also times
where readability may improve. This can be difficult to judge.
There are cases where Stateflow has more efficient code than Simulink for optimum expressions that
are close to code, but most of these result in a model that is difficult to understand. If code already exists,
it is more advantageous to use S-functions instead of Stateflow modelling. Stateflow can note
computations where specific arrangements are specified, or computations using for-loops, more efficiently
than Simulink, but in recent years it has also become convenient to use MATLAB language for
descriptions. If needed, consider using MATLAB language for modelling.
For Stateflow models, when dealing with states as described below, readability improves by describing
them as state transitions:
• Different output values are output for identical inputs.
• Multiple states exist (as a guide, three or more).
• States with meaningful names instead of just numbers.
• Inside a state, initialization (first time) and differentiation during execution (after the second time)
is required.
For instance, in flip-flop circuits, different values are outputted for inputs. State variables are limited to 0
and 1. However, a meaningful name cannot be added to each state simply by retaining Boolean type
numbers. There is also no distinction between initialization and execution within the state. Thus, only one
flip-flop applies out of the four above, so Simulink can be said to be more beneficial.
In Stateflow, situations that can be represented as states are implemented as state transitions and
conditional branches that are not states are implemented as flow charts. Truth tables are classified as a
conditional branch implementation method.
When designing states as state transitions by using Stateflow, “Classic” should be selected as the state
machine type so that it is implemented as software into the control system’s embedded micro controller.
HDL Coder is supported by Stateflow. If using HDL Coder, Mealy or Moore must be selected., Moore
mode is more appropriate when protection is required against internal electric leaks.
Note: HDL Coder use cases are not described in these guidelines.