Chart Properties

hisf_0001: State Machine Type

ID: Title	hisf_0001: State Machine Type
Description	To 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.
Rationale	Promote a clear modeling style.
Model Advisor Checks	Check 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	Specify Properties for Stateflow Charts (Stateflow) Create Mealy and Moore Charts (Stateflow)
Last Changed	R2018b

hisf_0002: User-specified state/transition execution order

ID: Title	hisf_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.
Prerequisites	hisl_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.
Rationale	A	Promote an unambiguous modeling style.
Model Advisor Checks	Check 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	Specify Properties for Stateflow Charts (Stateflow) Evaluate Transitions (Stateflow) Execution Order for Parallel States (Stateflow)
Last Changed	R2018b

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.
Rationale	A, B	Protect against unreachable code and unpredictable execution time.
Model Advisor Checks	Check 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' ISO 26262-6, Table 1 (1g) - 'Use of style guides' 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 Also	Specify Properties of Truth Table Functions (Stateflow)
Last Changed	R2017b