ted: use the filter command as in the case study to limit the number of signals in each process queue to one or two. 3. For each dynamically created process, use the command filter create process_name(n) to limit the successive process instance creations to n (do not confuse this limit with the declaration process_name(0, k), which only prevents having k process instances simultaneously, but does not limit the number of successive creation and stop). 4. Reduce the number of instances of each entity (block types etc.) and the number of repetitions such as retries to the minimum required for simulation. 5. Remove the declaration of temporary variables: an extension to SDL specific to ObjectGeode allows to omit the declaration of variables local to a transition, such as a variable receiving the input parameter of a signal. For example, writing sig1(x) in an input symbol, X does not need to be declared, if not used outside of the transition. Therefore, temporary variables are not stored in each global state of the system during simulation, reducing the number of global states. 6. Limit the number of external signals (feed) and the number of values you transmit as their parameters. Try to simulate separately independent features. 7. Replace the feed commands by one or several test processes representing external entities (such as a layer above a protocol): the behavior of such test stubs will be more realistic than feed, generally reducing the number of global states. 8. Limit the depth of the exploration, for example, to 1000. In this case, the simulation is no longer exhaustive. 7.7 ERRORS DETECTABLE BY EXHAUSTIVE SIMULATION In addition to the errors enumerated in Chapter 4, exhaustive simulation detects the errors described in this chapter. 7.7.1 Errors detected by Tau SDL Suite Tau SDL Suite Validator can detect the following errors: Deadlocks. Nonprogress loops: a subset of livelocks where if the loop contains inputs or outputs, it is not considered as nonprogress - in the maze example, the two loops are detected