 and modify an SDL variable The GOAL observer obsCond represented in Figure 5.82 detects if the variable X in process lights (see Figure 5.80) is > 0, and puts -99 into X. observer obsCond SUCCESS STATE good ; lights1 1!x>0> lights1 ! X :- 99 Figure 5.82 Detecting X > 0 and changing X 5.3.6.4 Using a GOAL observer to test the state of a process The GOAL observer obsState represented in Figure 5.83 detects if the state of process lights (see Figure 5.80) is equal to blue. observer obsState SUCCESS STATE good ; lights1 !state = lights1 ! blue Figure 5.83 Testing the state of a process observer obsCreate CREATE WRITELN WRITELN ('*** Instance of process created ***') ('*** Instance of process stopped ***) Figure 5.84 Detecting process creation and stop Automatic Observation of Simulations 165 Remember that the following probe is declared to access instance 1 of process lights: PROBE lights1 systl ! block1 ! lights (1) ; 5.3.6.5 Using a GOAL observer to detect process creation and stop The GOAL observer obsCreate represented in Figure 5.84 writes a message if there are any creation or stop of process instances in the SDL model. It is also possible to know which process has been created. Random Simulation 6.1 PRINCIPLES In the previous chapters, we have simulated interactively: when there was a choice between sev- eral SDL transitions to execute, the user selected manually the desired transition. For example, the user could send either an L_DataReq to transfer more data or an L_ReleaseReq to release a connection. In order to perform automatic simulations to test the maximum of model behaviors, the simulators provide an automatic mode, which we generically call random, where the choices between several firable transitions are made randomly. The simulation runs, executing thousand or millions of transitions, to test the SDL model quickly. When an error is encountered, such as a range overflow or a bad behavior detected by an observer, the simulation stops, and the user gets the error message and can use the debugging fea