Script based software for ground station and mission supportoperations for the Swedish small satellite Odin
Emil Vinterhav∗, Thomas KarlssonSwedish Space Corporation, Box 4207 S-171 04 Solna, Sweden
Received 28 October 2005; accepted 10 October 2006Available online 8 May 2007
Abstract
The small satellite Odin is a three-axis stabilised, high pointing accuracy, sub-millimetre, space observatory. One mean toattain as high efficiency as possible, which the Odin operations depend on, is the ability to quickly react to new input from thescience users as well as platform and payload behaviour.
Both the teams involved in the satellite operations are equipped with an easily accessible and modifiable set of software toolsfor monitoring telemetry and command generation. The software package is to a large extent based on scripts that have theadvantage of being legible to the user and not only to the developer. Matlab scripts are used in most steps in the operationscycle, save the actual execution of commands onboard the spacecraft.
Space systems are becoming increasingly complex.To fully take advantage of the spacecraft capacity theground support systems need to be increasingly versa-tile. In the Odin system, script based support softwareplays an important role to provide the conditions formaximum utilisation of the system’s capability.
The Odin satellite system has employed high level,interpreted programming languages as means to achieveflexibility in the ground segment operations. Supplyingthe tools for flexibility is only meaningful if it comes
∗ Corresponding author.E-mail addresses: [email protected] (E. Vinterhav),
with someone who has the capacity and the right touse them. The presence of the tools, and agents whohave the endorsement and the ability to use them andmodify them, ensure maximum utilisation of systemperformance.
2. The Odin space system
The Odin project is a co-operation between Sweden,France, Canada and Finland. It is a high performance,scientific satellite combining an earth sensing missionwith space observations at a low cost.
2.1. Satellite mission
Observing both the earth limb and deep-spaceobjects characterises the dual mission of Odin.
E. Vinterhav, T. Karlsson / Acta Astronautica 61 (2007) 912–922 913
A timeshare scheme is implemented where 50% of thetime is dedicated to monitoring the earth atmosphere(aeronomy mode) and the other 50% of the time is ded-icated to the study of deep-space sources (astronomymode).
Odin is equipped with a tuneable sub-millimetre sen-sor designed to detect molecules in space or in theearth atmosphere. Odin is also equipped with a slit-spectrometer (Osiris), working in the visible range ofthe spectrum, for observing the atmosphere.
2.2. Astronomy
Pointing accuracy and stability are essential whenOdin is in astronomy mode. Odin uses high performancestar trackers and gyroscopes to maintain a pointing sta-bility and accuracy of less than 10 arc seconds over longtime periods.
2.3. Aeronomy
When Odin is monitoring the atmosphere it does soby following a reference attitude in inertial space. Itdoes so because Odin is not equipped with earth sen-sors. The reference attitude is chosen so that it pointsthe line of sight for the instruments toward the earthlimb. Such a method for observing the earth atmosphereplaces a strenuous demand on orbit determinationand propagation as well as on pointing stability andaccuracy.
2.4. Satellite system
The Odin satellite system is made up of a space seg-ment and a ground segment.
Fig. 1. The Odin spacecraft.
2.4.1. SpacecraftOdin is a three-axis stabilised, zero momentum
micro-satellite, with a mass of 250 kg (Fig. 1). It hasa circular, solar synchronous orbit at 600 km altitudeand fills a full revolution around the earth every 97 min(Fig. 2). In the daytime 10 contact opportunities, eachlasting between 5 and 10 min, are given when the Odinpasses within the range of the ground station in Kirunain the north of Sweden (Fig. 3).
In the fine pointing modes (astronomy and aeron-omy) the attitude is determined (on board) twice persecond with two star trackers and solar sensors andpropagated at 16 Hz with gyroscope measurements.
Fig. 2. Odin is placed in a solar synchronous terminator orbit at600 km altitude completing a full revolution in 97 min.
Fig. 3. Odin’s orbital footprint over 24 h in green. The Kiruna groundstation visibility area is indicated by the red line.
914 E. Vinterhav, T. Karlsson / Acta Astronautica 61 (2007) 912–922
Fig. 4. Top: the stages (and teams) an observation passes on its way to execution on the spacecraft. The Odin Control Centre (OCC) teamhandles everyday operations while the Odin Mission Control (OMCC) handles communication with the science users. Below: the flow of datafrom the spacecraft back to the support operation teams and the science users.
The attitude is controlled with reaction wheels, whichin turn are unloaded with magnetorquers. In the coarsepointing modes, safe and standby, that do not use thestar trackers, magnetometers are used together with theSun sensors to get two inertial vectors from which theattitude is determined. Position data are collected froma GPS receiver for orbit reconstruction and propagationpurposes.
The star measurements from the star trackers and gy-roscope measurements are included with other sensordata in the stored housekeeping data and collected bythe ground station together with the data from the pay-load. The star measurements and gyroscope measure-ments are used for attitude reconstruction in the post-processing of data.
2.4.2. Ground segmentTwo teams are immediately involved in the ground
support for Odin. The ground station team operates ona short time frame, commanding the spacecraft andmonitoring telemetry and down-linked mass-memorydata for irregularities. The mission control team workson a longer time frame with validation of the ob-servation schedule and deeper analysis of spacecraftbehaviour.
The operation cycle is defined as: receiving observa-tions schedule from users, validation of schedule, plan-ning and generation of telecommands to implement co-ordinated execution of platform and payload activities,observation schedule execution and monitoring, recon-
struction of attitude and orbit trajectories and deliveryof level0 data to on-line repository (Fig. 4 and Fig. 1).
The timeline for the scientific observations is pro-cessed in the ground segment so that reference attitudesfor the platform are calculated, guide stars suitablefor the observations are selected and payload settingsare chosen. From the GPS data collected on board thesatellite trajectory is propagated and orbit parameterscalculated.
The stored housekeeping data are analysed to get amore complete knowledge of the satellite status. Param-eters that are monitored “off-line” include both platformand payload health and operations.
The orbit and attitude reconstructions are the onlyrefined data products delivered to the science users. Thereconstructed attitude is produced by the ground seg-ment as soon as a reconstructed spacecraft trajectory isavailable and delivered to the science users soon afterthe payload data are available at the data repository.
3. Script based software
The decision to use a high level interpreted language,Matlab, for Odin ACS support was taken with the intentof simplifying software development by involving thealgorithm designers in the code generation. This wouldresult in lower costs for code development and a bettercontrol of code behaviour.
The idea is that the logical and functional errorsin the software will be fewer and the times from
E. Vinterhav, T. Karlsson / Acta Astronautica 61 (2007) 912–922 915
conception to ready product shortened when the func-tion and algorithm designers have a chance to impacton the actual programming and test software that is stillin the maturing phase. To make this work it is impor-tant that the obstacle of programming and code legibil-ity be minimised and the implementation of algorithmsand functions be allowed to take centre stage. To reachthis situation it is necessary to write the software in aneasily accessible and versatile language. In the case ofOdin, Matlab scripting has been found to meet these re-quirements. Matlab has an intuitive interface, is familiarto large parts of the engineering community, adequatelyversatile and mature. Matlab scripts are used along theentire processing chain, i.e. pre-processing, monitoringand post-processing of data.
To further emphasise the simplicity and flexibilitywith script based software for ground station and mis-sion support for Odin, several scripts and functions inthe processing chain are explained below. Some of themare complex scripts, developed pre-launch during longtime and still changing. Others exemplify how the needfor a special function simply can be implemented as astand alone script or as an added function to an alreadyexisting script.
3.1. Make astro and make aero
The process chain starts with the production of satel-lite command files, or unvalidated timelines, uvt:s. Eachsatellite command file stretches from 1 to 30 orbits andit contains attitude and payload commands during theinterval. To produce uvt:s a script named Make Astrois used, and it takes a long astronomy schedule as inputand cuts it into appropriate lengths. Since the astron-omy schedule contains time gaps, the other script MakeAero fills the gaps with aeronomy measurements. MakeAero generates the complete uvt for each aeronomy ob-servation, including Radiometer and Osiris commands,instead of cutting an already existing schedule.
Both scripts were developed early in the project butthey have been manipulated through time. For exam-ple, the script Make Astro does now produce short cali-bration manoeuvre uvt:s when appropriate, to calibratealignment parameters of onboard equipment.
3.2. ScheVa
The central component in the group of command gen-erators for Odin operations is the scheduling and val-idation software, ScheVa. As input it takes a satellitecommand file, uvt, which contains the coordinates forthe astronomical object to observe or the aeronomy alti-
tudes to scan through. It allows the operator to adjust thereference and standby attitudes to keep the star trackersfrom pointing into the moon or a planet as well as toavoid the cold sky reference beams pointing in the di-rections of ”hot” areas of the celestial sphere. Further,the operator can monitor the angle between the solarpanel normal and the Sun in advance to ensure that themain reflector is always protected from the Sun by thesolar panels.
When the satellite command file is validated, theScheVa software generates a chronological list of com-mands to upload to the satellite. The list contains allnecessary information to perform a complete observa-tion, including star catalogues, Radiometer and Osiriscommands and attitude parameters.
As ScheVa is the application keeping track of the at-titude it is also handles antenna selection for the groundstation passages (Fig. 5).
The ScheVa was developed before Odin was launchedin Matlab and has been modified continuously duringthe project. New attitude manoeuvres, not intended be-fore launch, as well as new observational modes, havebeen developed and implemented. Many GUI changesand adjustments have been performed and many so-phisticated functions have been added throughout theproject.
3.3. PreProcessor
The PreProcessor is a very simple script that oper-ates on satellite command files before processing themin ScheVa. Due to reasons of uplink station design, ra-diometer mode names may not have longer names than10 + 3 letters. The PreProcessor parses the unvalidatedinput files and replaces names of modes according to anelaborate naming scheme. It converts the name of thecalibrations macros given in the astronomy schedule tonames that depend on radiometer mode used onboard.The names, which depend on radiometer mode, areunknown to the users (scientists) but necessary for thecorrect operation of the satellite.
This script is today a pure ‘find and replace’-functionbut it contains its own database of words to replace.The name PreProcessor is chosen because the scriptcan easily be modified to take care of any kind ofpre-processing. It was developed in a very short time.
3.4. Eclipse planner
The Eclipse planner is a comprehensive Matlabfunction added to the ScheVa software and it is usedto schedule daily commands related to the eclipses
916 E. Vinterhav, T. Karlsson / Acta Astronautica 61 (2007) 912–922
Fig. 5. The ground station passage (or communication) planning interface is a part of the ScheVa. To the left the orbit number identifying thepassage is listed and at the top the horizon mask for the ground based antenna is displayed.
Fig. 6. Eclipse planner displays the eclipses together with settings that are controlled by it.
during the annual period when the Sun is eclipsedby the earth for a section of the orbit. Since it is anadd-on to existing software it was easy to design andimplement and the time for development was relativelyshort. Most time was spent on writing source code,and little time was spent on design and on creating theGUI, making it appear exactly the way the operatorswanted it, without any loss of functionality.
After the Eclipse planner function was released, ithas been updated in several ways. More functions have
been included and the GUI (Fig. 6) has been changedto better fit the daily operations.
3.5. Soda
One of the products that the Odin system has to pro-duce is an accurate reconstruction of the attitude trajec-tory. Soda generates this trajectory and is a central com-ponent in the group of post-processing tools for Odinoperations.
E. Vinterhav, T. Karlsson / Acta Astronautica 61 (2007) 912–922 917
Fig. 7. Reconstructed telescope pointing for a Jupiter observationin degrees of right ascension and declination. The quality of thereconstruction is colour coded. A green mark indicates good quality,blue acceptable and a red mark indicates that the reconstruction isvery uncertain.
Soda has been updated and modified continuouslysince it was first commissioned at launch. New featuresand figures for analysis have been added. The scriptpackage now generates plots for most aspects of theattitude reconstruction, among them an intuitive quick-view of the pointing during the processed observation(Fig. 7). The attitude reconstruction has also been mademore robust allowing for more platform misbehaviourand data irregularities. Figures illustrating the contentsof the star trackers can be generated and updated in realtime as the reconstruction proceeds (Fig. 8). With theoption to show expected star tracker content superim-posed on the actual content these figures have provenvery useful both for enhancing the attitude performanceof the spacecraft as well as the robustness of the Sodaitself.
3.6. OdinStatus
One of the outputs from the Soda software is a textfile containing statistics from each post-processed satel-lite command file. To monitor the success of a partic-ular observation, or all observations during the wholeproject, one has to study this file and interpret the result.
To simplify this task OdinStatus was developed inMatlab. With this script the operator can monitor thewhole or any part of the mission graphically (Fig. 9),and special functions operating on the data from the fileare applied to achieve a clean overview of the attitude.Other algorithms can be added if further informationneeds to be extracted.
Fig. 8. The soda can be commanded to display the content of thestar trackers as it reconstructs the attitude. This gives the operatora preliminary idea of the attitude performance.
Fig. 9. The simple OdinStatus interface gives an easily interpretedpicture of recent attitude performance for Odin.
3.7. Power planner
Power planner is a tool for planning the onboardpower configuration. It takes the predicted angle
918 E. Vinterhav, T. Karlsson / Acta Astronautica 61 (2007) 912–922
Fig. 10. The Power planner interface allows the operator to input an authentic spacecraft power configuration.
between the solar panel normal and the Sun vector,together with the spacecraft configuration, as input andcalculates the number of solar cell arrays that needto be connected to the bus and the resulting shuntcurrent. The software has many tuneable parameterssuch as solar panel degradation, battery deterioration,end of charge levels and more (Fig. 10). It can han-dle passage situations when radio equipment is turnedon and eclipse dependent heater configuration. It wasdeveloped in Matlab and is used for complete powemonitoring.
3.8. Cal-gen
Two years after Odin was launched the payloadcalibration routines were changed, and the calibrationmacros became radiometer mode dependent. So insteadof having one set of calibration macros for all radiome-ter modes, each mode has its own set of calibrationmacros. The calibration macros are uploaded into mass-memory onboard Odin and executed on command. ThePreProcessor guarantees that the correct macros are
called since each macro name has to be changed in thesatellite command file.
There are more than 100 radiometer modes and thatrequired new tools that could generate these new setsof macros. Cal-gen was designed and implemented asa script in Matlab. It reads the radiometer mode defini-tions from an Excel work sheet and generates the cali-bration macros for all modes. The script is flexible andeasy to modify.
3.9. FrontEnd Script Generator, ScriptGen
As when generating calibration macros, all settingsfor the radiometer front end equipment are generated bya script that is called ScriptGen. It was developed beforelaunch in LabView, and has been slightly modified after-wards. The radiometer mode definitions are read fromthe same Excel work sheet as the one Cal-gen uses.
3.10. Plot timing
The list of commands generated by the ScheVa, canbe interpreted and displayed by the script Plot timing.
E. Vinterhav, T. Karlsson / Acta Astronautica 61 (2007) 912–922 919
Fig. 11. The attitude outcome of an observation toward Rho Oph. Green is reconstructed outcome, blue is planned fine pointing and red isstandby (contingency) planning. The graphs display various properties of the attitude trajectory.
Consequently, all observations can be inspected in ad-vance to again verify that all conditions are satisfiedfor one or several consecutive observations. Further, thetiming of all platform and payload commands is plottedtogether with the satellite mode, e.g. astronomy staringor aeronomy scanning mode (Fig. 11).
Plot timing can import the attitude reconstruction andsuperimpose the planned attitude trajectory on top of it.This makes it possible to cross reference commandedattitude to achieved attitude and study the differencesin detail.
Plot timing was developed in Matlab during Odin’sfirst year in orbit. It has been modified to work in newerversions of Matlab and more and more functionalityhave been added.
3.11. Flight View
Most of the analysing software in the Odin groundsegment presents data in the form of graphs with timeon the horizontal axis. Flight View is an add-on to plottiming that presents attitude data in 3D snapshots forany given timestamp in the monitored data. The toolpresents a view from the spacecraft centred along theline of sight for the radiometer instrument. The view canbe updated frequently enough to show a ”movie” visu-alising the attitude performance in an intuitive manner(Fig. 12). Flight View is mostly used for getting a moredirect understanding of attitude events thathave beenobserved in other tools and as a pedagogical tool fordemonstrating Odin observations in a spectacular way.
920 E. Vinterhav, T. Karlsson / Acta Astronautica 61 (2007) 912–922
Fig. 12. A snap-shot from the Flight View. The centred red dotindicates the line of sight for the payload. At this particular timestamp the payload is occulted by the earth.
SHocK View
-100
10
Battery Current (A)
28
30
32
34
Battery Voltages and Ueoc (V)
0102030
Battery Temperature (C)
-6-4-20
Amp-hour meter (Ah)
9
10
11
Main Bus Current (A)
Payload Currents (mA)
19 20 21 22 23 24 25 26 27 28 29
0
1000
2000
0
1000
2000
Hours
TS1 Misc, Supp struct, Cooler cmp and MT1 Currents (mA)
Fig. 13. SHocK View presents stored housekeeping data in graphs. The image shows the behaviour of the power system during the eclipse season.
3.12. SHocK View
A very important task of the ground segment is tomonitor housekeeping data closely. The SHocK Viewapplication for monitoring stored and downloadedhousekeeping data is essential for this task. SHocKView searches the telemetry definition database forinformation on how it should extract and interpret thedata set from the stored housekeeping data and presentsit to the user in graphs (Fig. 13).
3.13. ACS CheckIt
One of the most important tools for evaluating thesystem performance with respect to attitude control isACS CheckIt. The package is a collection of indepen-dent scripts that have been bundled together in order tomake them more accessible to the users. The package
E. Vinterhav, T. Karlsson / Acta Astronautica 61 (2007) 912–922 921
has tools for evaluating all on-board equipment relatedto attitude control including star trackers, gyros, agne-tometers, Sun sensors and the attitude control computeritself.
3.14. Zombie
Zombie is the natural next step for the monitoringsoftware. The tool is currently under development andwhen it is finished it will collect all the existing platformdiagnostic software into one package. It will become theapplication of choice for anyone engaged in monitoringthe spacecraft.
4. Experience
What are the benefits and drawbacks of using scriptbased software for ground support of a spacecraft suchas Odin?
The use of a high level scripting language weakensthe emphasis on software engineering and allows fora greater emphasis on functionality. By not havingto involve software engineers for code developmentbut instead having the designers of the algorithmsdoing the coding, the interface between designers ofalgorithms and designers of code has been removed.When the person developing the algorithm can realisehis ideas directly into code instead of having to ex-plain the functionality to a second person the domainfor misunderstandings is reduced to a correspondingextent.
The number of people involved in the devel-opment of the mission support software has beenkept down to three or four throughout the wholeprocess including the post launch phase. This hasmade development streamlined and has kept costsdown.
Due to the interpreted nature of scripted code thereis an extra layer of processing which slows downexecution. Matlab scripts can be compiled for extraperformance and so has been done for particularly de-manding scripts. When the scripts are run in compiledform they loose much of the accessibility that they hadas scripts and become more like executables in thatrespect.
High level computer languages are more accessibleto the generic user and scripting languages are to a largeextent legible to the technically literate. This enlargesthe group that is available for code validation and bugfixing. In Odin operations, those who have used the soft-ware in their daily work have augmented the softwarewith features that they have felt were needed. They have
fixed bugs when they have found them. Further, tools fordisplaying data have been provided through the script-ing language. This has made it easier to develop newways of visualising data.
The scripts are open, if not free, for anyone to edit.With the practical threshold for making a code up-date being virtually nonexistent the result is that thenumber of edits is higher than for traditional applica-tions. The manifold of updates might be a deterrentto choosing to use script based software and specialcare needs to be taken to assure code stability andfunctionality.
As scripts are interpreted languages and can beexecuted without compilation, changes take effectimmediately. Where the applications do not use acommunal library of functions, updates simply in-volve pasting of text files to a library. There is noneed for lengthy compilation of many applications de-pending on that particular library when an update isavailable.
The end users of the spacecraft, i.e. the scien-tists deciding on the observation schedule and usingthe data output from Odin, have been able to drawbenefits through new observational modes imple-mented rapidly and custom treated data for varioustests.
5. Conclusion
The use of script based software for the support op-erations of Odin has been a positive experience. Theevolvement of the software to match new requirementsand spacecraft behaviour has been facilitated by thechoice to use a script based programming language. Thecost for code development and maintenance has beenreduced because of the lack of need to involve dedi-cated software engineers. Special measures have beenneeded to be taken to ensure code stability and func-tionality but allowing for these measures there is stillmuch benefit to be drawn from the freedom of usingscript based software.
Further reading
[1] E. Vinterhav, B. Jakobsson, T. Karlsson, M. Nylund, T. Olsson,S. Lundin, U. Frisk, M. Westring, Short planning response timeand high flexibility of the astronomy/aeronomy satellite Odin,ISSFD-03-8.04 Proceedings.
[2] S. Lundin, S.-O. Silverlind, Odins third year in-orbit:normally smooth, occasionally dramatic, IAC-04-IAA.4.11.3.03Proceedings.
[3] U. Frisk, Status of the Odin project, IAC-04 IAA.4.11.2-02Proceedings.
922 E. Vinterhav, T. Karlsson / Acta Astronautica 61 (2007) 912–922
[4] S. Lundin, S.-O. SilverlindOdin, Odin two years in-orbit:staying alive but continuously tuned-in, IAC-03-IAA.11.3.05Proceedings.
[6] S. Lundin, Finding the balance between autonomy on-boardversus man-triggered actions from ground, IAC-02-IAA.11.4.4Proceedings.
[7] B. Jacobsson, M. Nylund, T. Olsson, E. Vinterhav, The high-performing attitude control on the scientific satellite Odin, IAC-02-A.P.13 Proceedings.
