0

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
  • 1
    Not sure if this is what you're looking for exactly, but your description put me in mind of a Viterbi diagram
    – paul
    Sep 18, 2014 at 16:21
  • 1
    To help get more insightful advice, please describe whether and how the software stores its "state". A common term for this is "persistence", or "Checkpointing (computer simulations)". If the underlying software has no support for these, and if the scripting system for initializing the software state is incapable of completely recreating a future time point in the scenario, there is nothing you can do. If the software runs in a virtual machine, you can snapshot it.
    – rwong
    Sep 18, 2014 at 16:53
  • @rwong Thank you for the tips, I will check those concepts, though they focus on storing a state that was set by the user (like a saved game). We do not need store the state persistently. It also doesn't run on a virtual machine. Sep 18, 2014 at 18:41
  • 1
    @SebastienGuimmara: It seems like you are indeed referring to persistence. Persistence as a concept is applicable to any software data, and applicable from both the programmer and end-user point-of-view. It would be a huge effort (sometimes impossible) to retroactively add persistence as a feature to existing or legacy software.
    – rwong
    Sep 18, 2014 at 18:59

2 Answers 2

2

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
  • It is probably the way we should do it. But when should it be recorded ? Is it a cached state ? In this case, it is not possible because it is too complicated to cache so many datas, and the cache would be out of date quickly, since the project is constantly evolving. We need a way to do it dynamically when the user clicks on the jump button. Sep 18, 2014 at 18:43
0

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.

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge you have read our privacy policy.

Not the answer you're looking for? Browse other questions tagged or ask your own question.