Setting State Machine Type restricts the Stateflow semantics to pure Mealy or Moore semantics. Mealy and Moore charts might be easier to understand and use in high-integrity applications.

In Mealy charts, actions are associated with transitions. In the Moore charts, actions are associated with states.

At compile time, the Stateflow software verifies that the chart semantics comply with the formal definitions and rules of the selected type of state machine. If the chart semantics are not in compliance, the software provides a diagnostic message.

• By Task > Modeling Standards for DO-178B > Check state machine type of Stateflow charts

• By Task > Modeling Standards for IEC 61508 > Check state machine type of Stateflow charts

• By Task > Modeling Standards for ISO 26262 > Check state machine type of Stateflow charts

• IEC 61508-3,Table A.7 (2) 'Simulation/modeling'

• ISO/DIS 26262-6, Table 1 (b) 'Use of language subsets'

• DO-178B, Section 6.3.1b 'High-level requirements are accurate and consistent'
  DO-178B, Section 6.3.1e 'High-level requirements conform to standards'
  DO-178B, Section 6.3.2b 'Low-level requirements are accurate and consistent'
  DO-178B, Section 6.3.2e 'Low-level requirements conform to standards'
  DO-178B, Section 6.3.3b 'Software architecture is consistent'
  DO-178B, Section 6.3.3e 'Software architecture conform to standards'

Do the following to explicitly set the execution order for active states and valid transitions in Stateflow charts:

In the Chart Properties dialog box, select User specified state/transition execution order.

In the Stateflow Editor View menu, select Show Transition Execution Order.

Set default transition to evaluate last.

Selecting User specified state/transition execution order restricts the dependency of a Stateflow chart semantics on the geometric position of parallel states and transitions.

Specifying the execution order of states and transitions allows you to enforce determinism in the search order for active states and valid transitions. You have control of the order in which parallel states are executed and transitions originating from a source are tested for execution. If you do not explicitly set the execution order, the Stateflow software determines the execution order following a deterministic algorithm.

Selecting Show Transition Execution Order displays the transition testing order.

• By Task > Modeling Standards for DO-178B > Check Stateflow charts for ordering of states and transitions

• By Task > Modeling Standards for IEC 61508 > Check usage of Stateflow constructs

• By Task > Modeling Standards for ISO 26262 > Check usage of Stateflow constructs

This guideline supports adhering to:

• IEC 61508-3, Table A.3 (3) 'Language subset'

• ISO/DIS 26262-6, Table 1 (b) 'Use of language subsets'
  ISO/DIS 26262-6, Table 1 (f) 'Use of unambiguous graphical representation'
  

• DO-178B, Section 6.3.3b 'Software architecture is consistent'
  DO-178B, Section 6.3.3e 'Software architecture conform to standards '

The following topics in the Stateflow documentation

• Transition Testing Order in Multilevel State Hierarchy

• Execution Order for Parallel States

To support strong data typing between Simulink and Stateflow ,

By default, input to and output from Stateflow charts are of type double. To interface directly with Simulink signals of data types other than double, select Use Strong Data Typing with Simulink I/O. In this mode, data types between the Simulink and Stateflow boundary are strongly typed, and the Simulink software does not treat the data types as double. The Stateflow chart accepts input signals of any data type supported by the Simulink software, provided that the type of the input signal matches the type of the corresponding Stateflow input data object. Otherwise, the software reports a type mismatch error.

• By Task > Modeling Standards for IEC 61508 > Check usage of Stateflow constructs

• By Task > Modeling Standards for ISO 26262 > Check usage of Stateflow constructs

• IEC 61508-3, Table A.3 (2) ‘Strongly typed programming language'

• ISO/DIS 26262-6, Table 1 (c) 'Enforcement of strong typing'

• DO-178B, Section 6.3.1b 'High-level requirements are accurate and consistent'
  DO-178B, Section 6.3.1e 'High-level requirements conform to standards'
  DO-178B, Section 6.3.1g 'Algorithms are accurate'
  DO-178B, Section 6.3.2b 'Low-level requirements are accurate and consistent'
  DO-178B, Section 6.3.2e 'Low-level requirements conform to standards'
  DO-178B, Section 6.3.2g 'Algorithms are accurate'

• MISRA-C:2004, Rules 10.1, 10.2, 10.3 and 10.4

To protect against unreachable code and indeterminate execution time,

Select the following run-time diagnostics:

• In the Configuration Parameters dialog box, on the Simulation Target pane, select:

  Enable debugging/animation

  Enable overflow detection (with debugging)

• In the Stateflow Debugging window, select

  State Inconsistency

  Transition Conflict

  Detect Cycles

  Data Range

For each truth table in the model, in the Settings menu of the Truth Table Editor, set the following parameters to Error:

Run-time diagnostics are only triggered during simulation. If the error condition is not reached during simulation, the error message is not triggered for code generation.

• By Task > Modeling Standards for DO-178B > Check Stateflow debugging settings

• By Task > Modeling Standards for IEC 61508 > Check usage of Stateflow constructs

• By Task > Modeling Standards for ISO 26262 > Check usage of Stateflow constructs

• IEC 61508-3, Table A.7 (2) 'Simulation/modeling'

• ISO/DIS 26262 Table 1 (d) 'Use of defensive implementation techniques'

• DO-178B, Section 6.3.1b 'High-level requirements are accurate and consistent'
  DO-178B, Section 6.3.1e 'High-level requirements conform to standards'
  DO-178B, Section 6.3.2b 'Low-level requirements are accurate and consistent'
  DO-178B, Section 6.3.2e 'Low-level requirements conform to standards'