The Simulator itself consists of several different components:
- The Vehicle Simulation model
Event loopfor generating vehicle events, run as either an Isolate or Web Worker depending upon the target platform.
- An optional
HTTP Server isolatefor exposing a REST API with basic vehicle controls - starting/stopping the vehicle, updating the vehicle state, handling vehicle notifications, and querying vehicle events.
As the simulation state can not be shared directly across the isolates, the simulation model in the main isolate acts as the source of truth across the system:
- Updates from the
Event loopare applied to the simulation model periodically, in line with the event generation frequency: once per second by default.
HTTP Server isolatemaintains its own cached copy of the simulation state, which is updated with changes from the Event isolate, UI interaction, and the REST API. Changes received through the REST API are cached in the
HTTP Server isolateand proxied back to the simulation model directly.
- The UI in the
main isolateis redrawn based on changes to the simulation model, triggered by UI interaction and updates from the
HTTP Server isolate.
An overview of the overall interactivity patterns for the different target platforms is provided below.
When running as a Web-based instance, the
Event Loop is implemented
in a dedicated Web Worker, analogous to the isolate-driven approach
used by the other platforms. In this case, the Simulation is run
entirely within the browser:
At present, it's not possible to serve the REST API from web-based instances, though a WebSocket implementation may be added in the future.
Other Target Platforms
For all other target platforms, the
Event Loop is run in a dedicated
isolate, and the REST API is directly exposed: