 Finally, the list of errors that can be detected by interactive simulation is presented, for the two Simulators used. 4.1 PRINCIPLES As soon as an SDL model is terminated1, it must be simulated interactively to check if its behavior is correct. The simulation allows the user to test the SDL model in an abstract and simplified world, and without waiting for the end of the coding or for the availability of the target hardware. In this simplified world, bugs are easier to find and correct than when the actual code is loaded into the target system, where the specification-level and design-level problems are complicated by coding-level issues. During interactive simulation, the SDL model is executed one transition or one symbol at a time, like in a debugger. To be consistent with the SDL ITU-T Recommendation [SDL92], a transition must be terminated before starting another transition. In other words, the execution of a transition cannot be interrupted, except when calling a remote procedure or when waiting for the user to provide the answer to an informal decision. Between two transitions or symbols, the SDL model is stopped and the contents of its variables can be displayed or modified. After the execution of a transition, the simulators evaluate which transitions are ready to be executed. If several transitions are ready, they are presented to the user who selects one to execute (ObjectGeode) or the oldest transition is proposed (Tau SDL Suite Simulator). By default, all the process instances have the same priority. During simulation, the SDL time progresses only if timers are started (in the real world, the SDL time progresses according to the real time, that is, even if timers are not used). After each interesting simulation scenario, the corresponding MSC trace or script can be stored into a file to be replayed automatically, for example for nonregression testing after modifications. Observers can be used to monitor the simulation, to automatically detect when the simulated behavior is or is not consistent with t