Experiments in space projects are excellent candidates for using portable simulators: the computer based experiment control, the s/w-model for classroom training, the s/w used to control a training or ground lab model and the onboard s/w-model for maintenance, all are parts of an experiment life cycle which benefit from using the portable simulator scheme, thus saving costs, being homogenous on each level and speed up development time.
Typical requirements for the interface definition of a portable simulator are presented. Ideas for managing the maintenance, the update and distribution are given, which may be a basis for standards for s/w development in this field.
1. Introduction
Combination of long term experience in training of astronauts for space missions and the advent in
computing and communications technologies have led to the development of the new set of training
tools - portable simulators.
Portable simulators are portable in two meanings: being location independent and/or being adaptable to different environments.
2. What do we call “Portable Simulator (PS) ”?
Two main criteria can be applied:
Both statements are illuminated by the following sketches.
2.1 PS in the life cycle of a space mission experiment
The important role of PS can easily be accepted having in mind, that PS is transportable and that PS's costs can efficiently be adapted due to the clearly defined interfaces.
2.2 Experiment Scenarios using the PS scheme
Real Experiment (for comparison)
Experiment Training with H/W
Experiment training on Classroom or Laptop (imbedded in CBT-Environment)
Let us look first on a real experiment and its elements. For our purpose it is practical to split it into the S/W- and H/W-part. The latter consists of the experiment itself and the man machine interface (MMI), e.g. frontpanels. As “experiment medium” on our sketch we call a summary of all objects to which the experiment is applied.
The user interacts in three ways: directly with the experiment medium (for example by taking a sample from an animal), via the man machine interface (e.g. switches, doors, etc.) and via the user interface of the S/W, mostly screen and keyboard of a computer.
Experiment training with hardware will be done normally to learn the use of the MMI. Therefore, frontpanels and serviceable parts are replicated in high fidelity, the experiment behavior itself is simulated by s/w models.
In case of applying the scheme of “Portable Simulators” the control software (C-S/W) of the original experiment can be used including the experiment parameters and - if applicable - the experiment sequences. Only models for the replaced hardware have to be developed, some new interface supplements for training specific h/w and add-ons in the user interface (UI) has to be coded.
Classroom training uses a simulation totally based on software. The man machine interface has to be simulated, too. In the PS scheme the MMI will be replaced by graphical representations extending the user interface to a GUI (graphical user interface). Again, control s/w and experiment parameters will be taken over 1:1 from the original.
This typical setup we call “a Portable Simulator”.
As indicated in the sketch, portable simulators are perfect candidates for the embedding into CBT scenarios. This offers the additional opportunity to include operator's training in the CBT course thus increasing significantly interactivity and attractivity of the CBT system.
Conclusion:
PS (portable simulator) is a - purely s/w driven - experiment simulator, which uses as much as possible of the original control s/w including experiment parameters and run cycle sequences. It has a comfortable GUI and modular organized hardware simulations with clear defined interfaces.
The PS scheme uses extensively the advantages of the PS, e.g. the flexibility for many different scenarios, the transportability for multiplying one development for many individuals or groups.
2.3 Details of PS development based on the Anthrorack experiment
Anthrorack is a human physiology experiment system that has been flown during Spacelab D2 Mission. Anthrorack software and hardware have been developed in cooperation between various research establishments and industry. The main objective of Anthrorack experiments was to perform measurements on the human subjects under microgravity conditions.
Anthrorack is a typical multipurpose system consisting of several independent subsystems, devoted to measure particular values and controlled by own computers. The overall activity of Anthrorack is supervised by the main computer that is linked to all subsystems via communication lines commanding the runs of experiment series. For this purpose a special command language (Command Sequences) has been developed by which the scientists of the Anthrorack team had the opportunity to flexible define their specific scenarios.
For the training simulator, located at the DLR, a software system based on a PC has been developed. While there was no need to simulate the many sensors placed on the subject body, the simulator was pretty realistic in regard to onboard operations. The operators could as in case of the real situation perform most of the actions on the main computer; in particular, they could load, start and let run original Command Sequences.
Although we had had no direct influence on the s/w development of the flight model of AR, fortunately the original design was of that kind that some premises for adapting the PS scheme were fulfilled:
- a core and a subsystem structure
- clearly defined interface between main- and sub- system
- experiment sequences in table form
It was not possible to take over the original control S/W. But at least two steps of experiment life cycle use the PS scheme: the training model and the classroom trainer. The latter was our prototype for portable simulators. From this we learn which requirements have to be formulated.
3. Requirements on Portable Simulator and the PS scheme
The portable simulator has some benefits by itself, but even more has the application of the PS scheme.
Main points of the scheme are:
Requirements for the Portable Simulator are:
- all experiment simulation is pure S/W
- it uses as far as possible the original experiment control/core software
- interfaces to the core s/w are identical as in the layout with h/w (but not the adapters)
- the existing user interface can be used
- if there is a man machine interface in the real experiment, it will be converted to a graphical user
interface
4. Ideas for maintenance
As already mentioned in chapter 2.1, portable simulators will play an important role during the life cycle of a space experiment or system. Main benefits for developing an experiment-S/W in PS scheme are:
- development is done only once and can be used multiple times
- behavior and parameters are identical in all derived applications
- experience of many working groups are focused on one result
Therefore, it is needed to concentrate all information at one location. One server, database or datapool shall be chosen as the distributor, which will hold the “original”. Due to the easy data communication all over the world, there is no need to change this location during the lifetime of the project.
A different story is the responsibility for the “original”. Our proposal is to change the responsibility as the development progresses:
At the beginning it is given to the group/person which has to do the most development at that time, e. g. the labs who create the experiment idea or simulator people which test the layout and make feasibility studies.
Later, it is shifted to the company, which built the H/W and have to imbed the S/W into the experiment.
In case of space experiments, a certain time before launch, control of changes has to be observed very carefully. That should be done by the project management, which consequently is the group in charge now.
In the time of data computing and developing of experiment results, normally the s/w of the experiment or models will not be changed anymore. Maybe, one will implement a section in the documentation which describes, what can be done better next time. In this case, responsibility is returned to the experimenters.
5. Future Aspects
Speaking about future developments, two trends shall be mentioned:
- extending the PS scheme to internet applications
- introducing the PS into VR (virtual reality) or vice versa.
It seems Important to us to note that standardization of the command interface and internal data transfer or at least data structures would help to realize exchange of s/w modules even between various projects/platforms.
Internet application
It was already shown that a PS could be embedded into a CBT environment. Computer based training, however, will use the Internet platform with its typical features HTML & JAVA, with which teletraining can be easily done. So, either we find good adapters between the classic PS and HTML based CBT or significant parts of PS uses that tool. The latter one is especially applicable to JAVA which provide attractive features in this context.
The advent of Internet also implies that in addition to job and/or education oriented training, portable simulators can also fulfil a number of task. As an example, we could imagine that manufacturers of video recorders could place a simulator on the web and ask future users their opinions about this product or do show them, how easy the handling is.
PS and VR
A typical situation of combining PS and VR is depicted in the following scene, where time delay of the remotely controlled experiment is significant.
Control in this case takes place by controlling a virtual device thus generating a set of command sequences. These commands are sent by telemetry to the remote experiment, which in turn uses these sequences as if they were given directly by the user.
Very obvious the point is, that most of control s/w could be used on both environments, if the vehicle is simulated as a PS. But, the vehicle model is part of a VR universe, which normally uses s/w tools very different from standard experiment programming tools. Again, standardization of internal data transfer may solve this problem.