19-10-2010, 01:18 PM
The rationale of this rule is to maximize the efficiency of a chart. Any actions within a single state (without any siblings at the same chart level) could be executed by the parent state without recourse to a state scheduler to manage the single state, i.e. the single state is generally unnecessary.
A single state at any level of a chart, particularly the root level of a statechart, is often seen to be indicative of an incomplete or erroneous design or implementation.
The single instance where we have seen a single state legitimately used is at the root level of a chart to enable the implementation of reset functionality in the chart, which strictly would then require a deviation from MISRA AC SLSF 039A. In this case the single super-state contains all logic for normal operation. A default transition into the state will handle normal entry into the superstate at first execution. A loop-back "reset" transition is placed on the super-state boundary to cause execution flow to exit the super-state and re-enter the super-state upon a reset event occuring. This re-entry causes reset/initialisation logic present via default transitions internal to the super-state to execute. As they say a picture is worth a thousand words, so hopefully the following example will illustrate the thinking behind the above exception.
![[Image: MISRA_%20AC_SLSF_039A_example.png]](http://www.misra.org.uk/Portals/0/MISRA_Images/MISRA_%20AC_SLSF_039A_example.png)
A single state at any level of a chart, particularly the root level of a statechart, is often seen to be indicative of an incomplete or erroneous design or implementation.
The single instance where we have seen a single state legitimately used is at the root level of a chart to enable the implementation of reset functionality in the chart, which strictly would then require a deviation from MISRA AC SLSF 039A. In this case the single super-state contains all logic for normal operation. A default transition into the state will handle normal entry into the superstate at first execution. A loop-back "reset" transition is placed on the super-state boundary to cause execution flow to exit the super-state and re-enter the super-state upon a reset event occuring. This re-entry causes reset/initialisation logic present via default transitions internal to the super-state to execute. As they say a picture is worth a thousand words, so hopefully the following example will illustrate the thinking behind the above exception.
<t></t>