. With a text editor, open the file v76. startup and add the comment delimiter -- as below to prevent the feed commands execution (because when an MSC is compiled with the SDL model, feeds are automatically created, making duplicates): source v76_feed.wri Random Simulation 177 C. In the SDL Editor, unload all files except v76.pr, and load the file testl.msc. D. Select Tools > SDL & MSC Simulator. E. In the ObjectGeode Launcher, remove any file other than v76.pr and testl.msc, press the Build button, then, if you do not get any errors, press the Execute button. The Simula- tor starts. F. In the Simulator enter the stop condition rstep = 1000. G. Press the button Traces: Off to speed up the simulation. H. Press on to start the random simulation: at Step 46 (you may get a different number), the simulation stops (unexpected signal). I. Press on init K four times on redo (to skip the start transitions) and then on the button: this time, the simulation stops at Step 59 (no receiver for output). J. Repeat the same sequence several times: the simulation stops, respectively, at Steps 41, 56, 46, 69 and 319 (you may get different numbers). K. You could continue the sequence init; redo 4; go many times, without reaching the observer MSC's success state. If you look at the MSC test1, this is normal: the probability to randomly simulate the successful connection, followed by an XID, then a data transfer and finally a connection release are extremely low. In our V.76 SDL model, there are several possible cascading simulation choices, as in a complex maze. Let's count the probability to verify the MSC: Step 4: choice between sending L_DataReq, L_EstabReq, L_SetparmReq or L_ReleaseReq to the SDL model; therefore, four possibilities, Step 5: choice between sending L_ReleaseReq or starting DLC process instance, Step 6: choice between sending L_ReleaseReq, timer T320 or input of v76frame, If we multiply all the number of possibilities offered at each step, we get: 4 x2x3x2x3x2x3x3x2x3x5= 77 760 to establish the connection (receptio