A simulator is an environment where a model can evolve and be tested without operating the real system. In the spaceship model, independent device actors run as lightweight threads while the simulator orchestrates their lifetimes and interactions. The actors remain unaware of this environment, communicating through an abstract request–response protocol. section 8.1.1 section 8.2.1
The simulator turns logic-control scripts into a specific environment. The same embedded domain-specific language can describe real subsystems and define the properties of their simulated counterparts, making the simulation model a compilation target rather than a separate application. section 8.1.1
A practical simulator interface separates three operations:
- Run a finite simulation, return its result, and complete the request. section 8.2.1
- Start an ongoing simulation without waiting for a result. section 8.2.1
- Shut down the simulation model and finish the simulator. section 8.2.1
Implemented as an actor, the simulator owns runtime state for controller simulations, messages, errors, and running threads. A worker receives requests through an MVar, runs or forks the requested logic control, and places finite results into a response MVar. This keeps request handling concurrent while preserving explicit state boundaries. section 8.2.1
Testing a simulation
An integration test creates simulator runtime state, starts the simulator, runs a logic-control script, stops the simulator, and checks the resulting runtime state. section 8.2.1 section 3.4
Figure 8.2 Real environment and virtual environment
Compare the real environment with the virtual environment in which simulated actors communicate. section 8.1.1
