ABSTRACT. This paper describes the experiences and lessons learned in using an off the shelf graphical simulation tool, ROSE, to develop a simulation of a fictional three axis stabilised, sun pointing spacecraft called MiniSV. As a result of this work we believe that higher quality spacecraft simulators can be developed for a significant fraction of the current cost. The advantages of using graphical modelling techniques for spacecraft simulation are described and we attempt to identify the features of a graphical modelling environment which increase development productivity. We examine how the use of graphical simulation tools changes the development lifecycle and propose some new ideas on how spacecraft simulators could be developed in the future.
The aim of this paper is describe the experiences and lessons learned in using a graphical modelling tool to develop a spacecraft simulator, therefore a basic introduction to the ideas and techniques of graphical modelling is necessary. The term graphical modelling is used to describe the development of a model through the manipulation of graphical icons representing objects. Graphical modelling can be thought of as an extension of the block diagram simulation methods which are currently becoming popular, with more emphasis on the amount of feedback to the user through the graphical icons.
Models in ROSE are built up from elementary objects stored in an object library. These objects, for example a solar panel, can be created and modified in an object editor, where both the attributes and behaviour are specified. The attributes of a solar panel object would include basic properties, such as panel area, normal vector, and efficiency; inputs, such as solar aspect angle and solar flux; and outputs such as power and solar radiation pressure force. The behaviour of the solar panel object is specified through lines of executable pseudo-code or an external call to an existing validated model. The pseudo-code uses the input parameters and the current object state to compute the output parameters and update the state. Each object is represented by a single graphic icon, created in a graphics editor, which is viewed at both design time and run time. The developer is also able to define the dynamic behaviour of the graphical icon with respect to the object state. The input and output parameters of the object are then associated with connect points on the object graphic icon so that the object may be connected to other objects.
Simulation models are built up from the objects stored
in the object libraries through a model editor. The model
is developed by dragging and dropping objects from the object
library onto a graphics page called a schematic. When an
object has been placed on a schematic its default attributes may
be set and connections to other objects created. As an example,
the size of a solar panel could be set to 3m2 and it
could be connected up to the power bus and the sun vector object.
At run time, the objects communicate through the connect points
by sharing common data. One object may calculate the sun vector
in the spacecraft body frame and pass this value on to the solar
panel, which determines the solar aspect angle with respect to
the panel normal vector. Objects on different schematics can be
connected together allowing objects to be grouped on schematics
according to spacecraft subsystems. Figure 1 shows the MiniSV
reaction control subsystem and some objects in the propulsion
library.
The model executable is created using a build utility that allows the developer to select which schematics to include in the simulation and the scheduling frequency. Thus a thermal model could be set to update at a low frequency, perhaps every second, and the spacecraft dynamics could be set to update 50 times a second. The executable is built in two stages. Firstly, code is generated for each schematic based on the objects which are present and how these objects are connected together. In some cases this is purely sequential code generation, however for the electrical and hydraulic networks the code is generated according to the structure of the whole network. This is known as non-sequential code generation. Secondly, the code is compiled and linked into an executable.
The model is run using a run-time utility that provides display and control facilities. The model is viewed through the same schematics that were used to create the model, therefore no extra effort is required in creating mimic displays. All the attribute values of an object can be displayed and modified through an object information box than is activated through a mouse click on the objects graphical icon. The graphical icon can also have dynamic touch areas, which enable the user to change the state of an object attribute with a mouse click. This feature allows circuit breakers to be opened and closed, eclipses to be forced and hardware units failed, all through a mouse click.
Several standard libraries in the spacecraft application domain have been developed within the ROSE environment. Table 1 lists these object libraries and some example objects.
In addition several other object libraries were developed as part of the MiniSV project. These are all basic libraries using sequential code generation. These libraries contain objects which model elements of MiniSV hardware, such as the flight computer, gyros & sun sensors, the uplink & downlink, data handling, telecommanding, formatting & displaying telemetry and the properties of a simple ground station.
The MiniSV simulator was originally a four month project to prove that a spacecraft operations type simulator could be built using ROSE. This first simulator included most spacecraft subsystems but lacked an orbit model. A second four month phase was undertaken to include an orbit model, a detailed model of the uplink & downlink and model a simple camera payload. The inclusion of an orbit model also allowed us to close the loop on the attitude control because the sun sensor inputs could now be used to generate realistic attitude errors. Many lessons learned from the first phase of the project were put into practice resulting in a substantially improved simulator.
The orbital model used in MiniSV was reused directly from an existing ROSE simulation. It took very little time to understand the structure of the new schematics and to integrate them into the existing simulation. Extra schematics were created to display key simulation parameters, such as the attitude and sub-satellite point, and to control important aspects of the simulation, such as forcing an eclipse or injecting a disturbance torque.
The shape of MiniSV is similar to EURECA, with solar panels mounted on two array wings. The solar arrays provide power to distribute to the hardware and charge the batteries. The bus voltage is regulated to the battery voltage by shunting excess power. All elements which require power are connected to the power bus and dissipate heat when turned on, which is input into the thermal model.
The attitude is controlled to keep the spacecraft sun pointing at all times. Gyros are used to sense the rates about the three axes and three sun sensors are used to detect the direction of the sun in the spacecraft body frame. All sensor information is collected across serial lines and processed by the flight software. The attitude is controlled by six 1N thrusters which are commanded to fire with a duty cycle calculated by the flight software. Six attitude control modes are implemented enabling MiniSV to de-spin, acquire the sun and remain sun pointing both in and out of eclipse.
The monopropellant hydrazine Reaction Control Subsystem is modelled as a hydraulic network of tanks, pipes and valves. The basic properties of volume, pressure and fluid conductivity can be set for each object in the system. At compile time the hydraulic code generator performs a network solution, based on the connectivity of the objects, which will calculate the pressures, temperatures and flow of fuel in pipes at run-time. The MiniSV RCS must be pressurised before the thrusters will function correctly. To fire a thruster the flow control valve upstream of the thruster is opened or closed according to the commanded thruster duty cycle. This causes fuel to flow into the thruster ignition chamber and cause a reaction force which is dependant on the fuel mass per second. All elements of the RCS must be powered to function.
A basic thermal model is included consisting of 16 nodes and 8 heaters. The nodal temperatures are influenced by heat input from the sun, thermal and physical properties of the outer spacecraft surfaces, heat input from the heaters and powered units and coupling to other nodes. The temperature of the six external panels and the gyros are monitored by the flight software and if the temperatures are outside operational boundaries commands are sent to switch heaters on or off accordingly.
At run time any one of six ground stations can be selected to monitor and control the spacecraft from. The link budget is calculated separately for the uplink and downlink and the and the final calculated carrier to noise ratio is then used to determine if a link is established. Telecommands are implemented to control most aspects of the spacecraft and it is possible to display and format the 200 telemetry parameters.
During the development of the MiniSV simulator several lessons were learned and techniques developed which are applicable to graphical modelling in general.
CODE GENERATION - The combination of graphical modelling and non-sequential code generation was responsible for the largest time savings during the MiniSV simulator development. Where the behaviour of a group of objects depends on how the objects are connected together the behaviour of each object would need to be modified according to its position in the network. Code generation is therefore saving many, many hours of work. As an example, extra thrusters could be added to the reaction control system and the corresponding changes in pressure upstream are taken care of because the code for the whole network is re-generated by every build.
PROTOTYPING - In a graphical simulation large changes can be made very rapidly, which would be very risky when writing code by hand. Prototyping several different approaches is possible because it is fast and the code is always regenerated in a self-consistent manner. During the development of the rf_link library several different approaches to modelling the uplink and downlink were tried.
BUILD TIME - Quick build times are essential for a rapid development and test cycle. During the MiniSV development the build time was always below five minutes, in which time roughly 60000 lines of code were generated from the schematics, compiled and linked.
TUNING - It is important to be able to view an objects attributes and 'tune' the state variables while the simulation is running. This makes it faster to get the correct system behaviour of a group of interconnected objects. The initial values of object attributes are then updated to the 'tuned' values in the model editor. An example would be the MiniSV thermal model where the surface properties of the spacecraft outer panels were adjusted to give temperatures within acceptable limits.
SCHEMATIC TYPES - Schematics should be divided into three categories; Control, Display and Calculation. Control schematics are those used for controlling the state of the simulation, for example to force an eclipse, sending telecommands or re-initialise the orbit. Display schematics are those used for displaying the orbit elements, the spacecraft position, satellite to ground station range, total power, or link budget. Calculation schematics are those which model the dynamics, the propulsion subsystem or the link budgets. It is best to break down schematics into these classes because the calculation schematics are generally larger and are usually unnecessary to view in the final simulation. Sometimes a schematic will be in all three categories as is the case for the electrical network models where the voltages and currents are displayed, and breakers can be forced open or closed.
GRAPHICS - Graphics should appear the same at design and at run time. It was also found that good graphic icons help greatly in finding problems, even when not looking for them. In the MiniSV simulator, when a unit is powered some element of the graphic icon will change colour from grey to green. The colour red is reserved for hardware objects which are failed, or parameters which are forced, such as the eclipse status. The good use of graphics means that the current simulation state can be taken in by the user very quickly and 'visual debugging' of schematics can be performed.
TEST OBJECTS - It was found useful to add extra objects to help during testing and provide short cuts during the early implementation. In MiniSV there are extra objects to inject disturbance torques for testing that the dynamics and orbit models are functioning and to help test the attitude AOCS response to disturbances. There are also objects to switch on and off the solar radiation torque, air drag, gravity gradient and to force an eclipse or a downlink. All of these objects are not required in the final simulation but help to validate that the simulator is responding correctly to these events. This is approach can be dangerous when coding by hand, but with graphical modelling it is very easy to delete any test objects at the end of the development and be sure that the simulation remains self-consistent
LIBRARY DEVELOPMENT - The design of objects in a library goes through three stages. Initially existing validated code is reused directly in an object, usually resulting in a object with many inputs and outputs. These large objects are generally cumbersome and not reusable widely in different simulations. In the second stage the large objects are split up into several small objects which do not usually work together very well. In the third stage, as more experience of using the objects together is gained, the set of objects is modified and optimised and the interfaces become more stable. A good library will consist of the minimum set of objects necessary to model all situations. For really fast development libraries of validated, well documented libraries should be used. A great deal of work has gone into the code generators and the associated libraries.
OBJECT REUSE - Spacecraft specific or hardware specific parts of the simulation should be identified and the basic library objects should be designed so that the behaviour can be easily changed. This will make the library objects more generally reusable. For example, the solar cell performance will be a function of the incident flux and the panel temperature which will depend on the cell material. This calculation could be made in a separate object so that the existing validated solar panel could be reused for different cell types. Another example would be a function describing the gain pattern of an antenna.
DOCUMENTATION - It was found to be very useful to attach text directly to the schematics. This feature is analogous to commenting code and provides the developer with information which could be important in maintenance or if the schematic is reused. These comments can also tell the user how to operate the simulation. An example of this can be seen in Figure 1. It is also possible to view the design documentation for an object through the model editor and this is very useful when using a library for the first time. Good documentation should include limitations on the use of the object and information about the accuracy and amount of validation.
Graphical modelling tools have the potential to greatly increase the productivity of simulator developers. Assuming spacecraft simulators are developed in a similar way as today, then the productivity gains can only be fully exploited if the development lifecycle of a spacecraft simulator is changed accordingly.
REQUIREMENTS - The requirements phase is essentially unchanged, however particular attention should be paid to how the simulation should be run and what data needs to be collected. The requirements are usually straightforward, "It shall behave exactly the same as the spacecraft".
ARCHITECTURAL DESIGN - It is necessary to analyse the user requirements and decide whether they can be met with existing objects and schematics. Time can be spent prototyping any new objects or modifications to existing objects. The objects are the building blocks and need to be well designed not just in terms of the individual behaviour, but also in terms of the connections to other objects. The design of objects can sometimes only become optimised through several cycles of development and use. It is also important to try and estimate size and CPU requirements because there is slightly less control over this in graphical modelling than in conventional coding and there are generally more graphics. The architectural design should focus on the system architecture and not on the interfaces between objects, which are managed very well in a graphical modelling environment. The process of placing objects on a schematic is basically the same as drawing lines between boxes with a software design tool. More time can be spent on planning the reuse of existing code, especially if there is a requirement to use flight software, hardware in the loop or detailed 3-D visualisation.
DETAILED DESIGN - The detailed design phase consists of developing objects, placing objects onto schematics, connecting objects together, and then tuning object state variables to get the desired system behaviour. Quite often complete models can be reused with little modification, which not only saves development time but validation effort. Any modifications to existing schematics can be made with confidence, because of code generation the model will always remain self-consistent. For example, a propulsion subsystem with prime and redundant strings can be reused for a single string model by deleting the extra thrusters, valves and tanks. The developer will know that all references to the extra thrusters will be gone from the model, which is not always clear when dealing with textual source code. Experience has shown that it is best to start by implementing the orbit and environment models and then the power and reaction control subsystems.
TEST & VALIDATION - This phase can proceed together with the detailed design. The nature of the code generation means that test harnesses are automatically created by the build. For example, a solar panel can be tested in isolation by varying the input solar flux and temperature, before it is connected to the power bus. As unit testing is well supported it gets done, without any specific enforcement. It was found that testing became enjoyable because of the amount of feedback provided at run time. The quick turn around time encouraged a more dynamic cycle of development and testing. Within ROSE there is also a requirements tracking facility. Software requirements can be attached to specific objects and schematics, and requirement tracking can be performed automatically.
DOCUMENTATION - Documentation serves the following purposes. It communicates to members of the development team the design of the software, it provides visibility to the customer on how the software is being developed, it enables the end user to operate the simulator and it supports the maintenance or reuse of the simulator. In a graphical simulation much of the information on how the simulator is constructed is contained on the schematics. This information often needs supplementing with explicit text attached to the schematic to explain in detail how a control works, or what value is being displayed. The documentation of individual objects should also be available on line, describing how the object works, what it calculates, what it doesn't, what connections in requires and any limitations on its use or performance which are important to know. In general a graphical simulation should require less documentation for the developers, the users and for maintenance and the visibility to the customer is greatly improved as the progress is 'visible'.
MAINTENANCE - The simulator needs to be maintained in response to problems found with the modelling and new requirements which may arise. Within a graphical modelling environment it is quite possible for experienced users to find problems and fix them without requiring support, for example to change the position of a thruster in response to a design change. This may present challenges with existing support contracts. Users will also be able to pinpoint problems more accurately and pass this information on to the developers. The simulator developers will be less dependant on keeping the staff who developed the simulator, as a good graphical simulation will be easily maintainable. Graphical modelling can therefore reduce the cost of maintenance considerably in a long term project.
Given the speed of implementing a simulator using graphical modelling techniques, how does this change the development strategy of a traditional operations type spacecraft simulator? Such a simulator can now be developed rapidly by spacecraft engineers rather than a team of software engineers who do not necessarily understand how spacecraft work. The engineer would spend most of his time creating models, testing and validating, rather than debugging code or worrying about implementation issues. Taking things a step further, such a simulator could be developed by a single engineer working on the spacecraft operations team over a period of a year or two. The simulator could be used by members of the team in the early phases of the project helping them to understand and define the operations concept. The other members of the team could feed their knowledge and experience into the simulator at an early stage to ensure accurate modelling. The simulator would also be a very good self paced training tool on how the spacecraft works for new members of the team.
Maybe a good spacecraft simulator will already have been developed as part of the design phase? This simulator will probably not be suitable for an operations simulator, perhaps a better ground model would be required, there would be strict real time requirements and a different way of controlling the simulation and recording the data. At the very least certain key models could be easily reused, as has been proved with MiniSV, such as the electrical, propulsion or orbit models. Over time updates in the flight software and certain other models would also be required in response to design changes. At the present time simulator developers must work from design documents, in the future they could use validated graphical models of subsystems, developed during the design phase.
There is a lot more that could be done to facilitate the easy sharing of simulation models. Looking at simulation in general there is a clear split between the modelling of the system and the way the model is run. Graphical modelling speeds up the development of the models, but the run time environment is very important as it is depends on the purpose of the simulation.
A simulator required for training a spacecraft operations team needs to run in real time and only occasionally faster, for instance to speed through a period of little or no operational activity. The major problems are in configuring the simulator correctly for a particular mission phase. Once the simulation starts the simulation conductor should only need to inject failures and monitor the performance of the operations team. The operations team interact with the simulator purely through the spacecraft control system to monitor telemetry and send telecommands. The simulator is also run in real time if it being used by the spacecraft launch team to validate operational procedures
If the simulation is being used for design purposes then the simulator will most often be run in a different way. A design engineer usually wishes to run rapidly through many 'what if' scenarios, collecting the results for later analysis with as little work as possible. This usually means defining a test script, collecting the results and then using another tool off line to analyse the data and make a design decision. The development of the various models (electrical, thermal dynamics) or elements of them (solar panel, heater, attitude integrator) could be shared between engineers wanting to simulate different aspects of the simulator at different levels of detail. The simulator model is essentially the same as for an operations and training simulator, perhaps more detailed in certain areas, but the run time environment needs to be different.
It is possible using graphical modelling with code generation to take the same models but build the executable code differently using different code generators (in any language, platform) for different purposes. The build/run time part of simulation can be de-coupled from the modelling part.
Other reasons spacecraft simulation may be for development and testing of onboard software or for the simulation parts of Electrical Ground Support Equipment. All these different simulations can make use of the many of the same models but with different run time constraints and different interfaces (Virtual Reality, Hardware In The Loop, Mission Control System).
The MiniSV can now be used as a starting point for the simulation of future, hopefully real, spacecraft. The design has ensured that the non generic parts of MiniSV can be easily de-coupled and that other parts can be upgraded easily as requirements dictate.
To speed up the development of self-consistent dynamics models, a prototype dynamics code generator has been developed. Objects, such as a solar panel, are given mass and position properties so that the code generator can automatically write the code which will calculate how the spacecraft behaves in response to thruster forces, solar radiation pressure and deployments.
Some more advanced ideas have been suggested which should be possible to implement within the ROSE environment. The thermal model could be generated automatically from a SINDA file, perhaps with a reduced number of nodes. Structural information from a CAD model could be used to generate code which calculates shadowing effects, and mass properties. If all spacecraft design information is in electronic form then it is possible to envisage using this information to create a complete real time operations simulation at the press of a button. A different button could produce a simulator to help design the power subsytem.
A note of warning should be added. The main benefits
of code generation are speeding up development, facilitating reuse
and ensuring the self-consistency of the model. As more code generation
is added, there can be a trade off between visibility of the modelling
and speed of development, however the developer will always have
the choice of either method.