 book, or from an SDL model, for example coming from a protocol standard, or from legacy code that must be reverse-engineered because no useful specification documents exist; 2. Interactive simulation, offering a good level of validation and automatic nonregression test- 3. Exhaustive simulation, the top level in validation, reserved for safety-critical or cost-critical systems. Cost-critical means that leaving errors in the system would be very expensive, because its code will be embedded into millions of devices. Simulation produces a low-default executable specification, plus reference MSCs (sequence diagrams) that provide an excellent documentation and which can be used as test cases to test the system implementation: as they have been generated by simulation, they are consistent with the validated SDL model. low-default textual spec. executable create interactive exhaustive SDL spec. SDL model simulatable simulation simulation SDL model reference legacy code Figure 1.3 The three simulation steps Step 1 is shown in Figure 1.4: if an SDL model exists for the system, it must be compiled. If there are errors, the SDL model must be corrected. Some SDL models may need to be com- pleted, for example to add missing data type declarations. If no SDL model exists, a decision must be taken to use or not to use SDL: if the system is not complex or not safety-critical, such an investment is not necessary. Beware of systems that seem to be simple but are not, in terms of behavior. Then, if the system (or a part of it) cannot be modeled using extended finite state machines communicating with signals through queues (a kind of mailbox), use another language, such as a synchronous language. Otherwise, continue with Step 2. Step 2 is shown in Figure 1.5: first, the main scenarios (the use cases) are simulated step by step. Each scenario is stored (files .scn, .com or .cui) to be replayed automatically later. Each MSC trace is also stored. When an error is found, the SDL model (or an specification if it is wrong) is corrected. 