OpenSatKit - A Flight Software System Educational Platform

OpenSatKit (OSK) provides a free educational resource originally created for spacecraft flight software (FSW) developers to adopt and use NASA’s open-source core Flight System (cFS) that has expanded to include applications for space systems curriculum, STEM educators and hobbyist. In 2015 the NASA Goddard Space Flight Center (GSFC) open sourced the cFS and a spacecraft dynamic simulator called 42. In the same year Ball Aerospace open sourced their COSMOS user interface for command and control of embedded systems. OSK combines these three systems into aground-flight-simulator software system. The cFS is an open architecture allowing users to port the core Flight Executive (cFE) to a platform (processor/operating system) of their choice, select/configure cFS community apps and develop custom platform software/apps to complete their system. The cFS has a long successful flight heritage ranging from CubeSats to large NASA GSFC observatories and a bright future that includes NASA’s Commercial Lunar Payload Systems program and the international lunar Gateway program. The cFS’ open architecture and collection of open-source community apps is part of what makes it so valuable, but they can complicate system integration increasing the learning and adoption curve. For the past few years, OSK’s features, and functionality have expanded to include a cFS-based reference mission called SimSat that includes over 20 apps and a YouTube channel with more than 15 training videos. These resources capture institutional knowledge and lesson learned from years of FSW experience. While these advances have helped many organizations learn and adopt the cFS, it has created some complexity challenges of its own. To address these challenges OSK is being reorganized to present material based on user tasks and goals. If a user wants to use the cFS for their CubeSat then the top-level tasks include acquiring/implementing a CFS platform port, identifying/integrating existing cFS apps for some of their mission’s functionality and developing new platform and app-level software for the remaining functionality. OSK provides task-based activity diagrams with examples, instructional videos, demo scripts, and exercises for each activity. OSK has expanded beyond its initial primary cFS-based FSW use case and can be applied to STEM education in general. The cFS has been ported to the low-cost Raspberry Pi processor and connected to OSK’s COSMOS instantiation. A series of code-as-you-go (CAYG) exercises and videos are in production that teach users how to port the cFS to the Pi and add software for managing sensors and actuators. This paper describes the new OSK organization and features that provide free FSW educational resources. OSK allows students to develop skills and apply them to meet their educational needs that will transfer into marketable skills as they enter the technical workplace

Flight Software Math Library

The flight software (FSW) math library is a collection of reusable math components that provides typical math utilities required by spacecraft flight software. These utilities are intended to increase flight software quality reusability and maintainability by providing a set of consistent, well-documented, and tested math utilities. This library only has dependencies on ANSI C, so it is easily ported. Prior to this library, each mission typically created its own math utilities using ideas/code from previous missions. Part of the reason for this is that math libraries can be written with different strategies in areas like error handling, parameters orders, naming conventions, etc. Changing the utilities for each mission introduces risks and costs. The obvious risks and costs are that the utilities must be coded and revalidated. The hidden risks and costs arise in miscommunication between engineers. These utilities must be understood by both the flight software engineers and other subsystem engineers (primarily guidance navigation and control). The FSW math library is part of a larger goal to produce a library of reusable Guidance Navigation and Control (GN&C) FSW components. A GN&C FSW library cannot be created unless a standardized math basis is created. This library solves the standardization problem by defining a common feature set and establishing policies for the library s design. This allows the libraries to be maintained with the same strategy used in its initial development, which supports a library of reusable GN&C FSW components. The FSW math library is written for an embedded software environment in C. This places restrictions on the language features that can be used by the library. Another advantage of the FSW math library is that it can be used in the FSW as well as other environments like the GN&C analyst s simulators. This helps communication between the teams because they can use the same utilities with the same feature set and syntax

Incorporating Manual and Autonomous Code Generation

Code can be generated manually or using code-generated software tools, but how do you interpret the two? This article looks at a design methodology that combines object-oriented design with autonomic code generation for attitude control flight software. Recent improvements in space flight computers are allowing software engineers to spend more time engineering the applications software. The application developed was the attitude control flight software for an astronomical satellite called the Microwave Anisotropy Probe (MAP). The MAP flight system is being designed, developed, and integrated at NASA's Goddard Space Flight Center. The MAP controls engineers are using Integrated Systems Inc.'s MATRIXx for their controls analysis. In addition to providing a graphical analysis for an environment, MATRIXx includes an autonomic code generation facility called AutoCode. This article examines the forces that shaped the final design and describes three highlights of the design process: (1) Defining the manual to autonomic code interface; (2) Applying object-oriented design to the manual flight code; (3) Implementing the object-oriented design in C

Increasing Flight Software Reuse with OpenSatKit

In January 2015 the NASA Goddard Space Flight Center (GSFC) released the Core Flight System (cFS) as open source under the NASA Open Source Agreement (NOSA) license. The cFS is based on flight software (FSW) developed for 12 spacecraft spanning nearly two decades of effort and it can provide about a third of the FSW functionality for a low-earth orbiting scientific spacecraft. The cFS is a FSW framework that is portable, configurable, and extendable using a product line deployment model. However, the components are maintained separately so the user must configure, integrate, and deploy them as a cohesive functional system. This can be very challenging especially for organizations such as universities building cubesats that have minimal experience developing FSW. Supporting universities was one of the primary motivators for releasing the cFS under NOSA. This paper describes the OpenSatKit that was developed to address the cFS deployment challenges and to serve as a cFS training platform for new users. It provides a fully functional out-of-the box software system that includes NASA's cFS, Ball Aerospace's command and control system COSMOS, and a NASA dynamic simulator called 42. The kit is freely available since all of the components have been released as open source. The kit runs on a Linux platform, includes 8 cFS applications, several kit-specific applications, and built in demos illustrating how to use key application features. It also includes the software necessary to port the cFS to a Raspberry Pi and instructions for configuring COSMOS to communicate with the target. All of the demos and test scripts can be rerun unchanged with the cFS running on the Raspberry Pi. The cFS uses a 3-tiered layered architecture including a platform abstraction layer, a Core Flight Executive (cFE) middle layer, and an application layer. Similar to smart phones, the cFS application layer is the key architectural feature for users to extend the FSW functionality to meet their mission-specific requirements. The platform abstraction layer and the cFE layers go a step further than smart phones by providing a platform-agnostic Application Programmer Interface (API) that allows applications to run unchanged on different platforms. OpenSatKit can serve two significant architectural roles that will further help the adoption of the cFS and help create a community of users that can share assets. First, the kit is being enhanced to automate the integration of applications with the goal of creating a virtual cFS "App Store".. Second, a platform certification test suite can be developed that would allow users to verify the port of the cFS to a new platform. This paper will describe the current state of these efforts and future plans

OpenSatKit Enables Quick Startup for CubeSat Missions

The software required to develop, integrate, and operate a spacecraft is substantial regardless of whether it’s a large or small satellite. Even getting started can be a monumental task. Every satellite mission requires three primary categories of software to function. The first is Flight Software (FSW) which provides the onboard control of the satellites and its payload(s). Second, while developing a satellite on earth, it is necessary to simulate the satellite’s orbit, attitude, and actuators, to ensure that the systems that control these aspects will work correctly in the real environment. Finally, the ground has to be able to communicate with the satellite, monitor its performance and health, and display its data. OpenSatKit provides these three software components in an open source software package. It combines NASA’s Core Flight System (cFS)1,2, NASA’s 423 spacecraft dynamics simulator, and Ball Aerospace’s COSMOS4 ground system into a system that can be deployed and operational within hours. OpenSatKit is designed to simplify the task of integrating new FSW applications and an example Raspberry Pi target is included so users can gain experience working with a low-cost embedded hardware target. All users can benefit from OpenSatKit but the greatest impact and benefits will be to SmallSat missions with constrained budgets and small software teams

Making Space for NASA\u27s Core Flight System Applications

NASA’s core Flight System (cFS) is an open-source flight software framework that runs successful space missions. However, even with growing adoption, cFS can have a challenging learning curve and incomplete documentation. Our new Base Camp toolkit is a new open-source approach developed to help remedy these problems for cFS applications. Base Camp combines NASA Glenn Research Center’s cFS Electronic Data Sheet (EDS) toolchain and refactored components from the author’s OpenSatKit (OSK) to provide a lightweight, portable, python-based toolkit. This toolkit allows users to graphically interact with a cFS target running an OSK Runtime App Suite that provides essential functionality like command ingest, telemetry output, file transfer, and onboard file management. EDS is a Consultative Committee for Space Data Systems (CCSDS) standard that is used to define app interfaces. The Base Camp toolchain uses EDS to automatically generate artifacts for the python ground system. This model enables automated app integration and provides the infrastructure for a cFS community app exchange. The Runtime App Suite is compatible with NASA’s cFS Caelum, the same cFS version used by the NASA Artemis Gateway program. Base Camp is a parallel effort with OpenSatKit. OpenSatKit goes further by combining Ball Aerospace’s COSMOS ground system, NASA’s cFS, and NASA’s 42 dynamic simulator to create an end-to-end cFS-based reference system. And it includes 20+ preconfigured applications. While helpful to users whose goal is a cFS-based space mission, OSK’s complexity can be daunting for user’s who have much simpler goals, such as a cFS-based STEM educational project. Base Camp comes preconfigured with an app suite that facilitates cFS education. From there, OSK apps have been moved to individual git repositories allowing users to decide which apps to integrate into their Base Camp project. Base Camp also includes tools that generate Hello World apps and tutorials that step students through a series of lessons that teach more advanced cFS features. These tutorials have been successfully used for virtual training classes, in-person training classes, and for independent learning. Educators can use Base Camp or step advanced students up to OSK, either of which can run on low-cost Raspberry Pi configurations. This paper describes Base Camp’s features and illustrates how they allow NASA’s cFS framework to be utilized for flight missions as well as STEM education. Base Camp allows students to develop skills and apply them to meet their educational needs that will transfer into marketable skills as they enter the technical workplace

cFS Basecamp: A Flight Software STEM Education Ecosystem

The open-source core Flight System (cFS) Basecamp ecosystem includes several cFS-based STEM educational projects and provides the infrastructure for users to create their own. Basecamp\u27s tool suite and app repositories function much like a smartphone\u27s App Store model. The initial cFS Basecamp installation includes several built-in tutorials that help users learn NASA\u27s cFS application environment and shorten their path to productivity. Online resources describe Basecamp\u27s goal-oriented software/hardware projects. These projects are designed so students understand how to create app-based solutions to meet a particular goal. This approach evolved after years of being engaged with teaching the cFS and learning which teaching methods were most effective. Users began by installing a lightweight Python GUI with minimal external dependencies. This approach helps avoid platform-specific issues so Basecamp can be used in classroom settings where students have diverse computing platforms. With Basecamp\u27s GUI installed, students are ready to work on projects. A preinstalled demonstration app in conjunction with a self-guided tutorital helps users understand an app\u27s command/telemetry interface and the cFS application runtime environment. A built-in app generation tool creates a Hello World app to help students take a first step into cFS app development. From there, they can work through Code-As-You-Go (CAYG) lessons that introduce topics. Each new topic is reinforced with hands-on exercises. These lessons are more suitable for instructor-led classes that can be held virtually or in person. The next level of projects requires Basecamp\u27s github app repositories. Using the GUI, students can select and install Basecamp cFS apps from github with only a few mouse clicks. For example, the General-Purpose Input/Output (GPIO) Demo project requires a cFS Raspberry Pi interface library and an app to control an LED connected to a Raspberry Pi through the GPIO connector. To implement this project, students first connect an LED to a Raspberry Pi, install Basecamp on the Pi, download/install the library/app, and rebuild/run the cFS. A second Basecamp instance installed on a separate computer can remotely control the Raspberry Pi. This is achieved by using Basecamp\u27s MQTT Gateway app. This app utilizes the Internet of Things (IoT) MQTT messaging service that has freely available broker services. Basecamp\u27s modular approach with plug \u27n play cFS apps make it an ideal platform for creating STEM educational projects. These projects will help students learn valuable hardware/software skills while using NASA\u27s award-winning flight software that has a large user base in the aerospace community

Magnetospheric plasma pressures in the midnight meridian: Observations from 2.5 to 35 RE

Plasma pressure data from the ISEE 2 fast plasma experiment (FPE) were statistically analyzed to determine the plasma sheet pressure versus distance in the midnight local time sector of the near-earth (12–35 RE) magnetotail plasma sheet. The observed plasma pressure, assumed isotropic, was mapped along model magnetic field flux tubes (obtained from the Tsyganenko and Usmanov [1982] model) to the magnetic equator, sorted according to magnetic activity, and binned according to the mapped equatorial location. In regions (L ≳ 12 RE) where the bulk of the plasma pressure was contributed by particles in the energy range of the FPE (70 eV to 40 keV for ions), the statistically determined peak plasma pressures vary with distance similarly to previously determined lobe magnetic pressures (i.e., in a time-averaged sense, pressure balance normal to the magnetotail magnetic equator in the midnight meridian is maintained between lobe magnetic and plasma sheet plasma pressures). Additional plasma pressure data obtained in the inner magnetosphere (2.5 \u3c L \u3c 7) by the Explorer 45, ATS 5, and AMPTE CCE spacecraft supplement the ISEE 2 data. Estimates of plasma pressures in the “transition” region (7–12 RE), where the magnetic field topology changes rapidly from a dipolar to a tail-like configuration, are compared with the observed pressure profiles. The quiet time “transition” region pressure estimates, obtained previously from inversions of empirical magnetic field models, bridge observations both interior to and exterior to the “transition” region in a reasonable manner. Quiet time observations and estimates are combined to provide profiles of the equatorial plasma pressure along the midnight meridian between 2.5 and 35 RE

The average magnetic field draping and consistent plasma properties of the Venus magnetotail

A new technique has been developed to determine the average structure of the Venus magnetotail (in the range from −8 Rv to −12 Rv) from the Pioneer Venus magnetometer observations. The spacecraft position with respect to the cross-tail current sheet is determined from an observed relationship between the field-draping angle and the magnitude of the field referenced to its value in the nearby magnetosheath. This allows us statistically to remove the effects of tail flapping and variability of draping for the first time and thus to map the average field configuration in the Venus tail. From this average configuration we calculate the cross-tail current density distribution and J × B forces. Continuity of the tangential electric field is utilized to determine the average variations of the X-directed velocity which is shown to vary from −250 km/s at −8 Rv to −470 km/s at −12 Rv. From the calculated J × B forces, plasma velocity, and MHD momentum equation the approximate plasma acceleration, density, and temperature in the Venus tail are determined. The derived ion density is approximately ∼0.07 p+/cm³ (0.005 O+/cm³) in the lobes and ∼0.9 p+/cm³ (0.06 O+/cm³) in the current sheet, while the derived approximate average plasma temperature for the tail is ∼6×106 K for a hydrogen plasma or ∼9×107 K for an oxygen plasma

Physical correlations lead to kappa distributions

The recently developed concept of "entropic defect" is important for understanding the foundations of thermodynamics in space plasma physics, and more generally, for systems with physical correlations among their particles. Using this concept, this paper derives the basic formulation of the distribution function of velocities (or kinetic energies) in space plasma particle populations. Earlier analyses have shown how the formulation of kappa distributions is interwoven with the presence of correlations among the particles' velocities. This paper shows, for the first time, that the reverse is true: the thermodynamics of particles' physical correlations are consistent only with the existence of kappa distributions.Comment: 19 pages, 3 figure