We have a program that combines the simulation of an aircraft system and predefined pedagogical scenarios for trainee pilots to learn how to use this system.
When we follow the normal scenario, chapter after chapter, everything goes smoothly.
Now, when the trainee skips the chapter N and goes directly to the chapter N+1, the simulation goes snafu because the chapter N was not executed by the simulation, resulting in an incoherent state.
As a remedy, we write the desired simulation state in the scenario file, just after the chapter entry point.
The problem is it’s not possible to predict the simulation state for chapter N if we don’t know the scenario first by heart. And some scenarios are very complex. A developer has to spend a long time studying the scenario to get an accurate picture of what is expected by the trainee then he jumps to chapter N.
The software doesn’t need persistence. That is, we don’t have to save the simulation state when the program is not running.
The simulation state is managed by ~200 000 variables. It is not possible for us to make a snapshot of the simulation state at every step because it would be highly impracticable, and each time the scenario is updated, the snapshot would be out of date.
We also don’t have access externally to all variables since some are private and are out of bounds (And even if we had access, it would be a bad idea, given the sheer amount of data).
Is it a common problem and are there best practices and known solutions to tackle this issue ?
4
Run the simulator through every step to N+1, and then record the state. When you want to jump to N+1, just restore the state you recorded.
1
The simulation state is managed by ~200 000 variables. It is not
possible for us to make a snapshot of the simulation state at every
step because it would be highly impracticable, and each time the
scenario is updated, the snapshot would be out of date.
This sounds like a problem not only for running the simulation at a given chapter, but also for testing it. In order to test something you need to know the preconditions, i.e. the expected state at the beginning of the test. It’s not reasonable to expect programmers working on a system that involves 200,000 variables to correctly foresee every effect of changes they make on the system, so automated testing seems like an absolute requirement for something like this.
The software doesn’t need persistence. That is, we don’t have to save
the simulation state when the program is not running.
While it may not be a requirement that you be able to save the state of the simulator for each trainee, the fact that you’re asking this question indicates that you do, in fact, need to be able to save the state of the simulation at various points so that you can load specific configurations on demand. Again, this will not only solve your problem, but also pay dividends in terms of testing and debugging.
If you cannot reasonably save the actual state of the simulation, another option is to be able to record and play back user actions. This is really just another way to record state, but instead of recording the state of the system at a given time, you instead record all the steps that get you to that state. In a deterministic system the same series of inputs will always result in the same final state. This approach may have some advantages — since you’re not recording the actual state of the system, it doesn’t matter if the way the system is implemented changes; all that matters is that the actions expected of the user at each step don’t change. Also, the space needed to record the user’s actions might not be as great as that needed to record the total state of the system.