Main Content

Chart Properties

hisf_0001: State Machine Type

ID: Titlehisf_0001: State Machine Type
DescriptionTo create Stateflow® charts that implement consistent Stateflow semantics, use the same State Machine Type (Classic, Mealy, or Moore) for all charts in the model.
Note

In Mealy charts, actions are associated with transitions. In the Moore charts, actions are associated with states. In Classic charts, actions can be associated with both transition and states.

At compile time, Stateflow 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.

RationalePromote a clear modeling style.
Model Advisor ChecksCheck state machine type of Stateflow charts (Simulink Check)
References
  • IEC 61508-3, Table A.3 (3) - Language subset

  • IEC 62304, 5.5.3 - Software Unit acceptance criteria

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

  • EN 50128, Table A.4 (11) 'Language Subset'

  • DO-331, Section MB.6.3.2.b 'Low-level requirements are accurate and consistent'

See Also
Last ChangedR2018b

hisf_0002: User-specified state/transition execution order

ID: Titlehisf_0002: User-specified state/transition execution order
Description

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

A

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

Prerequisiteshisl_0311: Configuration Parameters > Diagnostics > Stateflow
Note

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.

RationaleAPromote an unambiguous modeling style.
Model Advisor ChecksCheck Stateflow charts for ordering of states and transitions (Simulink Check)
References

This guideline supports adhering to:

  • DO-331, Section MB.6.3.2.b 'Low-level requirements are accurate and consistent'

  • IEC 61508–3, Table A.3 (3) 'Language subset'
    IEC 61508–3, Table A.4 (5) 'Design and coding standards'

  • IEC 62304, 5.5.3 - Software Unit acceptance criteria

  • ISO 26262-6, Table 1 (1b) 'Use of language subsets'
    ISO 26262-6, Table 1 (1e) 'Use of well-trusted design principles'
    ISO 26262-6, Table 1 (1f) 'Use of unambiguous graphical representation'
    ISO 26262-6, Table 1 (1g) 'Use of style guides'

  • EN 50128, Table A.4 (11) 'Language Subset'
    EN 50128, Table A.12 (1) 'Coding Standard'
    EN 50128, Table A.12 (2) 'Coding Style Guide'

See Also
Last ChangedR2018b

hisf_0011: Stateflow debugging settings

ID: Title

hisf_0011: Stateflow debugging settings

Description

To protect against unreachable code and indeterminate execution time,

A

Set configuration parameters Wrap on overflow and Simulation range checking to error.

In the model, open the Debug tab and select Diagnostics > Detect Cyclical Behavior

B

Right-click on each truth table in the model and select Properties. Set these parameters to Error:

  • Underspecification

  • Overspecification

Notes

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.

RationaleA, BProtect against unreachable code and unpredictable execution time.
Model Advisor ChecksCheck Stateflow debugging options (Simulink Check)
References
  • DO-331, Section MB.6.3.2.b 'Low-level requirements are accurate and consistent'

  • DO-331, Section MB.6.3.3.d 'Software architecture is verifiable'

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

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

  • IEC 61508-3, Table A.4 (5) - Design and coding standards

  • IEC 62304, 5.5.3 - Software Unit acceptance criteria

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

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

  • ISO 26262-6, Table 1 (1d) - 'Use of defensive implementation techniques'

  • ISO 26262-6, Table 1 (1e) - 'Use of well-trusted design principles'

  • ISO 26262-6, Table 1 (1f) - 'Use of unambiguous graphical representation

  • EN 50128, Table A.3 (1) - Defensive Programming

  • EN 50128, Table A.4 (8) 'Strongly Typed Programming Language'

  • EN 50128, Table A.4 (11) - Language Subset

See AlsoSpecify Properties of Truth Table Functions (Stateflow)
Last ChangedR2024a