Developing a Software Tool to Enable Creation of Command Scripts for a Satellite Mission

DEVELOPING A SOFTWARE TOOL TO ENABLE CREATION OF COMMAND SCRIPTS FOR A SATELLITE MISSION Erik Keoni Wessel Department of Physics University of Illinois at Urban Champaign Urbana, IL 61801-3080

INTRODUCTION Mid-May - August 2014, I worked for the Hawai‘i Space Flight Laboratory (HSFL) in the University of Hawai‘i at Mānoa as a programmer for the upcoming Hiakasat satellite mission. During my internship, I helped to develop COSMOS (Comprehensive Open- architecture Space Mission Operations System), a suite of software systems and tools that the Hiakasat mission will use both on the ground and on the satellite itself (Sorenson, et. al., 2012). My primary project was the creation of a new software tool to support the COSMOS flight software. This application, called the Command Assembler Tool (CAT) is crucial for the generation of command scripts, files that are sent to the satellite to control it. It can also be used to view logs sent back from the satellite. SKILLS LEARNED This project gave me the opportunity to hone my existing computer science skills and acquire several new ones. I gained hands-on experience with the COSMOS flight software that CAT supports by writing test routines for satellite hardware. I learned how COSMOS monitors and controls the satellite. I also gained experience with Qt, a cross-platform application and GUI framework (http://qt-project.org/), while writing the application in C++ and Qt’s QML language. My first task was to write test programs for the satellite. Being able to test the satellite’s systems regularly as it is prepared for launch is crucial for the mission. Each piece of hardware requires its own test program, and at the time my internship started a program was needed to test the spacecraft’s magtorque (magnetic torque) rods. Magtorque rods are a set of three perpendicular electromagnets that help control the rotation of the satellite by interacting with the earth’s magnetic field. To test them, the program I wrote ramped up and down the current in each magtorque rod and compared the magnetic field measured by internal sensors with the expected flux values at regular intervals. Additionally, I wrote a bash script that runs all the test programs in sequence, allowing quick verification that the satellite is in working order. Testing the satellite hardware provided perspective and hands-on knowledge about the flight software. Understanding how COSMOS flight software systems work was essential. A collection of programs on the flight computer are responsible for controlling and monitoring the satellite. While the satellite is still on the ground we can manually run these programs and view their output, but after launch this will no longer be practical. Instead, a special program called “agent_exec” (which is set to start running as soon as the flight computer boots up) runs and monitors all the other programs for us. Agent_exec itself then takes commands and relays output through files sent to and from the satellite.

64 In order to communicate with agent_exec, there must be a way to describe any events that can happen in a general sense, be they commands that might be executed or other events that have occurred or will occur on the satellite. COSMOS describes all types of events with a single data structure called an “eventstruc,” detailed in the table below (Figure 1.). COSMOS has functions that can convert any COSMOS data structure into a text double utc TheFigure event ’1.s universaleventstruc timestructure coordinate members. (UTC) representation in JSON (JavaScript Object Notation), and vice-versa. This allows eventstrucs to be written to and(http://www.hsfl.hawaii.edu//cosmos/documentation/structeventstruc.html read from text files which can be transferred over the radio between) the satellite anddouble ground stations.utcexec The time the event was actually triggered

char node [] COSMOS Node for the event

char name [] Name of the event

char user [] User of the event

uint32_t flag Event flags

uint32_t type Event type

double value Current value of the condition

double dtime Initial time consumed

double ctime Continuous time consumed

float denergy Initial energy consumed

float cenergy Continuous energy consumed

float dmass Initial mass consumed

float cmass Continuous mass consumed

float dbytes Initial bytes consumed

float cbytes Continuous bytes consumed

jsonhandel handle The handle of the condition that caused the event (NULL if timed)

char data [] Data associated with the event

char condition Condition that triggers the event (NULL if timed) [] 65 Two lists of events are sent to the satellite, which agent_exec constantly monitors: a queue of pending commands and a dictionary of physical events that can happen (such as going into shadow behind the Earth). Events can be triggered in two ways. If an event does not have a condition specified, then agent_exec will trigger it as soon as the current time passes the event’s UTC. If an event has a condition string, that string is evaluated every cycle after the event’s UTC is reached, and the event is triggered if the condition is true. Events that have been triggered temporarily remain on the list with their flag set to “true” (so other COSMOS software can see them) and are then copied to an event log and removed from the list (unless their flag is set to “repeat”). The event log is transmitted back to ground regularly. Eventstrucs representing commands have a unix terminal command in their associated “data” string, which agent_exec will run when they are triggered, allowing remote control of the satellite. The Qt framework and QML were chosen to aid the development of CAT (details to follow). Qt is an open-source C++, cross-platform application and user interface framework, which all COSMOS GUI tools have been written in so far (http://qt-project.org/). It allows GUI software applications to be written that can then be built to run on Mac, Windows, or Linux machines. Applications can be written in C++ and/or QML (Qt Meta-object Language), a declarative language with embedded JavaScript snippets that is highly suited for user interface development (http://developer.ubuntu.com/apps/qml/). Several days were spent researching QML before even beginning work on the project, and the Qt documentation proved an invaluable resource while developing this software tool. Knowledge of both Qt and COSMOS was foundational to being able to build CAT, and through the project I got better at software design, honed my C++, and learned to write QML code. SOFTWARE DESIGN & IMPLEMENTATION Creating the CAT in support of the COSMOS flight software was an exercise in efficient, goal-oriented software design and programming. Before beginning, it was very important to consider which needs the CAT was addressing, and how it would do so. Once the goals of the project had been decided, major design decisions had to be made that would guide the development. Finally, the minor details of the implementation were fleshed out during coding process. The CAT was meant to be a simple tool that would let COSMOS event logs be viewed, and COSMOS command queues and physical event dictionaries be viewed, edited and created. In the MPST specifications it was stated that MPST would contain a horizontal timeline running from left to right to provide a visual overview of event sequences. While CAT is distinct from MPST at present, implementing a QML version of the timeline not only makes CAT more useful, but furthers the development of COSMOS as a whole by laying the groundwork for a QML-based MPST. CAT also needed to give users the ability to manage lists of events, adding, moving, and reordering them as need be. Every property of every event would also have to be quickly viewable and editable via the GUI. Finally, the application needed to be able to load and save out JSON text files containing COSMOS event lists. Having determined the goals of the project, my task was then to use the tools provided by COSMOS and the Qt framework to achieve them.

66 Several key decisions guided the development of the application. As mentioned previously, I chose to build the application in C++ and QML, within the Qt framework. QML makes building GUIs much quicker, the language is designed for that task, and since it is interpreted at runtime by the QML engine there is no need to recompile during development in order to test changes (http://developer.ubuntu.com/apps/qml/). However, C++ code would still be needed to configure and launch the QML engine, and to use the COSMOS libraries and services. I decided to structure the application so that there was a straightforward division of labour between the C++ and QML sides of the application. QML would handle the application GUI and C++ would manage the application back end. Thus, the visual interface and all calculations and objects relating to it would be managed and defined in QML, while C++ would take on file I/O and the storage of and all processing related to the event lists. This structure makes the program better organized, easier to debug, and easier to update with new features. The only drawback is that it means the program is not likely to be as performance optimized as it could otherwise be, but this isn’t a concern for realistic cases. With a clear outline of the CAT completed, it was time to start writing actual code, discovering and solving any new problems in a practical, hands-on manner. The key to interaction between C++ and QML is the Qt Meta-object system and the associated QObject class included in Qt. QObjects are a C++ class, instances of which can, within the framework of Qt, be accessed from both QML and C++ if passed into the QML engine. Qt Meta-object properties can be defined on QObject-derived classes by defining property accessor functions (functions to get and set the property’s value), and these properties can then be accessed in QML just like properties on any QML object. Functions on QObjects can also be made callable from QML via the Qt Meta-object system. Upon startup, the C++ main function creates two objects: a QML engine and a “CommandAssembler” object (a custom QObject-derived class), a reference to the latter is then passed to the engine. The CommandAssembler object provides the QML GUI access to the C++ back end of the application. Since the application relies on users being able to modify COSMOS events, eventstrucs must be accessible to QML, so a QObject eventstruc wrapper class called “Event” was created that bade each member of an embedded eventstruc accessible as a Qt Meta-object property. I wrote a third class, called “SharedObjectList”, to allow lists of objects to be shared between C++ and QML, something not yet supported by default in the Qt framework. Using COSMOS’s JSON parsing functions, a function on the CommandAssembler can parse an event file into eventstrucs, and store them as Event objects inside a SharedObjectList that can be edited by the GUI. Another function can extract the eventstrucs from the SharedObjectList of Events and save them to an output file. As with any software project, there were more minor design choices made and small problems fixed during the implementation stage than it is possible to detail in a paper, but ultimately the major goals of the project were achieved. RESULTS

67 As it stands, the CAT has the all the functionality required to adequately address the need for a simple command script writing and event log reviewing tool for COSMOS. There are numerous ways to view and edit event lists and individual events within the application. The main window is divided into two major sections: the timeline and the event list views (Figure 2).

Figure 2. Screenshot of the finished Command Assembler Tool

Across the top half of the window is a multi-lane horizontal timeline. The timeline can be zoomed in and out via the scroll wheel, controlling the exponent of a horizontal scale multiplier, to enable fine control over large scale ranges. Holding down shift enables side-to-side scrolling with the scroll wheel, which can also be achieved with the scroll bar at the bottom of the timeline. The timeline is divided into 5 lanes. A label area on the left lists the types of events displayed in each lane, and the labels are color coded to match the color of the events they correspond to. Pairs of enter and exit events (such as entering and exiting the Earth’s shadow) are drawn as a colored bar stretching along the timeline.

68 Conditional events have a blur extending to their right down the timeline, which illustrates visually the possibility that they might not be executed immediately when their UTC is passed (Figure 3, previous page). When the mouse is moved over the timeline, a vertical green line appears, and text appears in a box at the top that displays the cursor’s exact UTC. The bottom half of the window contains two tabbed regions. The left set of tabs displays table views of either the command queue, a list of projected future events (at this point the application does not yet predict future events based on information about the satellite and its trajectory, but it is a planned feature), or a list archival events. Events in these three lists are also displayed in the timeline. The right set of tabs contains table views of the physical event dictionary, and a dictionary of command events that can be easily copied into the command queue. These two event dictionary lists are not drawn on the timeline. All lists can be loaded from event files or saved to event files via buttons above the lists, or corresponding items in the main menu (Figure 4).

Figure 4. Saving the command queue to a file

69 Right-clicking on the events or the timeline brings up a menu that allows new events to be created, either by copying them from a template in one of the dictionaries, or creating a new blank event (Figure 5). Additionally there is copy/paste functionality allowing events to be copied between or within any of the 5 event lists the application manages. Clicking and

Figure 5. Context menu options for creating an event based on those in the command dictionary list. dragging on events, or the bar connecting an enter/exit event pair, will change those events’ UTCs. A context menu lets the user bring up an event properties dialog for any event (Figure 3.), where all the event’s properties can be viewed and edited. Events can be selected in either the timeline or lists, and will be highlighted in dark blue in both the timeline and lists when selected. Events can be selected, and subsequently copied, pasted, deleted or edited, in groups. CONCLUSION At this point the Command Assembler Tool has the necessary functionality to be used to make command scripts for the satellite. Lists of commands can be made quickly, aided by the ability to copy and paste and replicate template commands from a command dictionary list. It is possible to load, edit, and save any of the 5 lists Command Assembler manages, the command queue, projected list, archival list, command dictionary and event dictionary, and the files outputted are suitable for commanding the flight software. There is still room for improvement, the next step would be to add the ability to simulate the satellite to a limited extent, predicting future events and modeling resource consumption. However, as it stands the software application has achieved its primary purpose.

70 This internship has given me experience writing software applications. I have gotten better at working within the Qt framework, and learned how to use the QML language to build advanced GUIs. I have also learned about the COSMOS flight software systems, and been able to do hands-on work writing software to control hardware on a real spacecraft. I feel I have gained many useful skills during this internship, and have contributed something of value to the COSMOS and Hiakasat projects. ACKNOWLEDGEMENTS I would like to thank Eric Pilger for mentoring me during the project, and answering lots of questions about COSMOS and Hiakasat, Trevor Sorenson for explaining the design of COSMOS’s MPST program and the format of timelines needed for mission planning, and Ethan Kastner for tolerating sharing an office with me this summer and answering numerous technical questions. I would also like to thank the Hawai‘i Space Grant Consortium, for making this all possible, and everyone at HSFL for their hard work on the coolest engineering project I have ever had the privilege of being a small part of. REFERENCES Sorenson T. C., Pilger E. J., Wood M. S., Nunes M. A., Yost B. D., 2012, A University- developed Comprehensive Open-architecture Space Mission Operations System (COSMOS) to Operate Multiple Space Vehicles, SpaceOps 2012, 11-15 June, conference Stockholm, Sweden Qt Project, http://qt-project.org/, Accessed 8/15/2014 QML, http://developer.ubuntu.com/apps/qml/, Accessed 8/15/2014 COSMOS Software Documentation, http://cosmos-project.org/docs/software-documentation, Accessed 8/15/2014 Eventstruc Struct Reference, http://www.hsfl.hawaii.edu//cosmos/documentation/structeventstruc.html, Accessed 8/15/2014 Longeventstruc Struct Reference, http://www.hsfl.hawaii.edu//cosmos/documentation/structlongeventstruc.html, Accessed 8/15/2014