Flight software trends and patterns in the aerospace industry: JPL lessons learned
In this paper, we will summarize the software trends and their impact on the cost of developing flight and ground software.
software trends↗
SEARCH · Engineering Papers
Results for “Ground Software”
Search indexed NASA NTRS and DOE OSTI research on propulsion, heat transfer, battery materials and energy systems. Follow report and document links to the original sources.
Quote a phrase for an exact phrase match. Source license links do not imply unrestricted reuse.
Flight Software Dictionary Development for the Mars2020 Rover
The Mars2020 project, developed and operated by the Jet Propulsion Laboratory (JPL), successfully landed the Perseverance rover and its flying companion Ingenuity on the surface of Mars on February 18th 2021. Perseverance combines heritage and cutting-edge flight software and hardware to accomplish crucial mission requirements related to Martian surface sampling. The design, development, and operation of NASA’s large strategic science missions require the ability to communicate spacecraft capabilities to hundreds of engineers across multiple disciplines. The interaction between flight and ground software development, Verification and Validation (V&V), Assembly, Test, and Launch Operations (ATLO), and management each demand quick understanding of unique slices of information for each discipline. This information includes the current capabilities of the flight system as well as future capabilities and their status as they are developed and tested. Despite the fundamental and critical nature of this information, the flight software dictionaries used to track it are a stumbling block for many projects. These dictionaries provide the cornerstone for the interpretation of data sent from the spacecraft, allowing for quick comprehension by engineers on the ground. During both spacecraft development and operations, flight software dictionary management includes significant challenges due to the large number of interfacing systems and the subtle yet distinct needs of each.The engineering of flight software dictionaries for Mars2020 had numerous challenges, most-notably: parallel dictionary development to support simultaneous separate flight software build campaigns for each mission phase (cruise and surface), managing requests for operations-enabling information without perturbing the heritage interface with the rover, and the introduction of new tools by the dictionary stakeholders that forced the dictionary team to innovate and redesign the heritage tool chain. These challenges generated guiding principles for the dictionary development effort: emphasize coding best practices and unit testing in the dictionary code development tool chain, use institutionally provided COTS (commercial-off-the-shelf) tools whenever possible, and maintain the heritage flight-ground interface all while advancing operations-enabling information via a loosely coupled interface.Throughout development and operations, the Mars2020 dictionary toolchain included IBM DOORS Next Generation, GitHub, Microsoft Excel, Docker, Jenkins, and a significant custom-built Python codebase. Significant interfaces included JPL’s command and control software, heritage flight software team tools and processes, and the many cloud-based ground tools developed for the mission.This paper will discuss the requirements for the Mars2020 dictionary development, the development team’s response to those requirements, lessons learned throughout the process, steps taken towards automated deliveries and continuous integration of stakeholder inputs, potential toolchain improvements for Mars2020, and key takeaways that could be applied to future missions.
Pyrzak, Guy↗
The NASA Mission Operations and Control Architecture Program
The conflict between increases in space mission complexity and rapidly declining space mission budgets has created strong pressures to radically reduce the costs of designing and operating spacecraft. A key approach to achieving such reductions is through reducing the development and operations costs of the supporting mission operations systems. One of the efforts which the Communications and Data Systems Division at NASA Headquarters is using to meet this challenge is the Mission Operations Control Architecture (MOCA) project. Technical direction of this effort has been delegated to the Mission Operations Division (MOD) of the Goddard Space Flight Center (GSFC). MOCA is to develop a mission control and data acquisition architecture, and supporting standards, to guide the development of future spacecraft and mission control facilities at GSFC. The architecture will reduce the need for around-the-clock operations staffing, obtain a high level of reuse of flight and ground software elements from mission to mission, and increase overall system flexibility by enabling the migration of appropriate functions from the ground to the spacecraft. The end results are to be an established way of designing the spacecraft-ground system interface for GSFC's in-house developed spacecraft, and a specification of the end to end spacecraft control process, including data structures, interfaces, and protocols, suitable for inclusion in solicitation documents for future flight spacecraft. A flight software kernel may be developed and maintained in a condition that it can be offered as Government Furnished Equipment in solicitations. This paper describes the MOCA project, its current status, and the results to date.
Ondrus, Paul J.↗
[Activities of System Studies and Simulation, Inc.]
Contents include the following: 1. Launch Vehicle Interface Work Performed: a. S3 provided to KSC the new launch inclination targets needed for the April '04 launch date. 2. Prelaunch operations work performed: a. S3 updated the staffing plan for MSFC on-console personnel\during the Final Countdown prior to launch. 3. Software Assessment Work Performed: a. S3 evaluated and recommended approval for Program Control Board (PCB) proposed change 649 for ground software changes, as well as change 650 and 650A for Stored Program Commands. 4. Education and Public Outreach Work Performed: a. S3 continues to coordinate the effort for the design and fabrication of scale models of the GP-3 for use at the launch site, education forums, and management/technical briefings. S3 also prepared a Change Request for additional funds needed for fabrication of additional scale models. S3 drafted the planned uses of these models, including the possibility of participation in the Boston, MA showings of the traveling Einstein Exhibit. 5. Program Management Support Work Performed: a. S3 prepared the input for and closed three MSFC Centerwide Action Item Tracking Systems (CAITS) actions during this period.
Source record↗
SEQ-REVIEW: A tool for reviewing and checking spacecraft sequences
A key component of JPL's strategy to make space missions faster, better and cheaper is the Advanced Multi-Mission Operations System (AMMOS), a ground software intensive system currently in use and in further development. AMMOS intends to eliminate the cost of re-engineering a ground system for each new JPL mission. This paper discusses SEQ-REVIEW, a component of AMMOS that was designed to facilitate and automate the task of reviewing and checking spacecraft sequences. SEQ-REVIEW is a smart browser for inspecting files created by other sequence generation tools in the AMMOS system. It can parse sequence-related files according to a computer-readable version of a 'Software Interface Specification' (SIS), which is a standard document for defining file formats. It lets users display one or several linked files and check simple constraints using a Basic-like 'Little Language'. SEQ-REVIEW represents the first application of the Quality Function Development (QFD) method to sequence software development at JPL. The paper will show how the requirements for SEQ-REVIEW were defined and converted into a design based on object-oriented principles. The process starts with interviews of potential users, a small but diverse group that spans multiple disciplines and 'cultures'. It continues with the development of QFD matrices that related product functions and characteristics to user-demanded qualities. These matrices are then turned into a formal Software Requirements Document (SRD). The process concludes with the design phase, in which the CRC (Class, Responsibility, Collaboration) approach was used to convert requirements into a blueprint for the final product.
Maldague, Pierre F.↗
A Flight-Calibrated Methodology for Determination of Cassini Thruster On-Times for Reaction Wheel Biases
This paper describes a methodology for accurate and flight-calibrated determination of the on-times of the Cassini spacecraft Reaction Control System (RCS) thrusters, without any form of dynamic simulation, for the reaction wheel biases. The hydrazine usage and the delta V vector in body frame are also computed from the respective thruster on-times. The Cassini spacecraft, the largest and most complex interplanetary spacecraft ever built, continues to undertake ambitious and unique scientific observations of planet Saturn, Titan, Enceladus, and other moons of Saturn. In order to maintain a stable attitude during the course of its mission, this three-axis stabilized spacecraft uses two different control systems: the RCS and the reaction wheel assembly control system. The RCS is used to execute a commanded spacecraft slew, to maintain three-axis attitude control, control spacecraft's attitude while performing science observations with coarse pointing requirements, e.g. during targeted low-altitude Titan and Enceladus flybys, bias the momentum of reaction wheels, and to perform RCS-based orbit trim maneuvers. The use of RCS often imparts undesired delta V on the spacecraft. The Cassini navigation team requires accurate predictions of the delta V in spacecraft coordinates and inertial frame resulting from slews using RCS thrusters and more importantly from reaction wheel bias events. It is crucial for the Cassini spacecraft attitude control and navigation teams to be able to, quickly but accurately, predict the hydrazine usage and delta V for various reaction wheel bias events without actually having to spend time and resources simulating the event in flight software-based dynamic simulation or hardware-in-the-loop simulation environments. The methodology described in this paper, and the ground software developed thereof, are designed to provide just that. This methodology assumes a priori knowledge of thrust magnitudes and thruster pulse rise and tail-off time constants for eight individual attitude control thrusters, the spacecraft's wet mass and its center of mass location, and a few other key parameters.
Earth Mean Equatorial↗
SCaN Testbed Software Development and Lessons Learned
National Aeronautics and Space Administration (NASA) has developed an on-orbit, adaptable, Software Defined Radio (SDR)Space Telecommunications Radio System (STRS)-based testbed facility to conduct a suite of experiments to advance technologies, reduce risk, and enable future mission capabilities on the International Space Station (ISS). The SCAN Testbed Project will provide NASA, industry, other Government agencies, and academic partners the opportunity to develop and field communications, navigation, and networking technologies in the laboratory and space environment based on reconfigurable, SDR platforms and the STRS Architecture.The SDRs are a new technology for NASA, and the support infrastructure they require is different from legacy, fixed function radios. SDRs offer the ability to reconfigure on-orbit communications by changing software for new waveforms and operating systems to enable new capabilities or fix any anomalies, which was not a previous option. They are not stand alone devices, but required a new approach to effectively control them and flow data. This requires extensive software to be developed to utilize the full potential of these reconfigurable platforms. The paper focuses on development, integration and testing as related to the avionics processor system, and the software required to command, control, monitor, and interact with the SDRs, as well as the other communication payload elements. An extensive effort was required to develop the flight software and meet the NASA requirements for software quality and safety. The flight avionics must be radiation tolerant, and these processors have limited capability in comparison to terrestrial counterparts. A big challenge was that there are three SDRs onboard, and interfacing with multiple SDRs simultaneously complicatesd the effort. The effort also includes ground software, which is a key element for both the command of the payload, and displaying data created by the payload. The verification of the software was an extensive effort. The challenges of specifying a suitable test matrix with reconfigurable systems that offer numerous configurations is highlighted. Since the flight system testing requires methodical, controlled testing that limits risk, a nearly identical ground system to the on-orbit flight system was required to develop the software and write verification procedures before it was installed and tested on the flight system. The development of the SCAN testbed was an accelerated effort to meet launch constraints, and this paper discusses tradeoffs made to balance needed software functionality and still maintain the schedule. Future upgrades are discussed that optimize the avionics and allow experimenters to utilize the SCAN testbed potential.
radio communication↗
Swift-BAT: The First Year of Gamma-Ray Burst Detections
The Burst Alert Telescope (BAT) on the Swift has been detecting gamma-ray bursts (GRBs) since Dec. 17,2004 and automated burst alerts have been distributed since Feb. 14,2005. Since commissioning the BAT has triggered on more than 100 GRBs, nearly all of which have been followed up by the narrow-field instruments on Swift through automatic repointing, and by ground and other satellite telescopes after rapid notification. Within seconds of a trigger the BAT produces and relays to the ground a position good to three arc minutes and a four channel light curve. A full ten minutes of event data follows on subsequent ground station passes. The burst archive has allowed us to determine ensemble burst parameters such as fluence, peak flux and duration. An overview of the properties of BAT bursts and BAT'S performance as a burst monitor will be presented in this talk. BAT is a coded aperture imaging system with a wide (approx.2 sr) field of view consisting of a large coded mask located 1 m above a 5200 cm2 array of 32.768 CdZnTe detectors. All electronics and other hardware systems on the BAT have been operating well since commissioning and there is no sign of any degradation on orbit. The flight and ground software have proven similarly robust and allow the real time localization of all bursts and the rapid derivation of burst light curves, spectra and spectral fits on the ground.
Krimm, Hans A.↗
Recent Results from the Swift Burst Alert Telescope
The Burst Alert Telescope (BAT) on the Swift Gamma-Ray Burst MIDEX mission has detected more than 125 gamma-ray bursts (GRBs), nearly all of which have been followed up by the narrow-field instruments on Swift through automatic repointing, and by ground and other satellite telescopes after rapid notification. Within seconds of a trigger the BAT produces and relays to the ground a position good to three arc minutes and a four channel light curve. An overview of the properties of BAT bursts and BAT'S performance as a burst monitor will be presented in this talk. BAT is a coded aperture imaging system with a wide (approx.2 sr) field of view consisting of a large coded mask located 1 m above a 5200 sq cm array of 32.768 CdZnTe detectors. All electronics and other hardware systems on the BAT have been operating well since commissioning and there is no sign of any degradation on orbit. The flight and ground software have proven similarly robust and allow the real time localization of all bursts and the rapid derivation of burst light curves, spectra and spectral fits on the ground.
Krimm, Hans↗
Using Artificial Intelligence and Machine Learning to Enhance Mission Design and Operations of the Habitable Worlds Observatory (HWO)
One key aspect in the development of HWO is the early deployment of artificial intelligence (AI) and machine learning (ML) to enhance mission science and operations. Our subtask group is part of the HWO AI/ML working group and focuses on AI and ML for mission operations. Our task group seeks to educate other HWO working groups about AI and ML capabilities for mission operations, investigate how to bridge technology gaps, and enable new capabilities particularly in the areas of observational scheduling, instrument health monitoring, and downlink operations. We focus on mission tasking / scheduling both for mission analysis in development and operations. AI and ML for mission scheduling includes: tools to support proposal calls and review, ensuring fairness in calls for proposals, community peer reviews and ease workloads, as well as in-flight and ground software development (e.g., using natural language processing (NLP) to support process automation from requirements). AI and ML for the mission’s development and operations include 1) anomaly detection and prediction (from onboard and ground based tools) to monitor the spacecraft’s health, 2) ground-based automated scheduling for mission operations including long-term and short-term planning and maintenance, and 3) flight system flexible execution (as flight proven for Spitzer and JWST) to enable robust execution despite execution variations, and 4) data analysis for prioritization (e.g., real-time data evaluation leading to autonomous actions and adjustments, high-priority identification, onboard data compression, etc.). Incorporation of ML and AI will enable HWO to address the major science questions related to exoplanet characterization, general astrophysics, and solar system exploration and also extend the boundaries of space mission technologies.
Mark Moussa↗
Astronaut Photography of the Earth: A Long-Term Dataset for Earth Systems Research, Applications, and Education
The NASA Earth observations dataset obtained by humans in orbit using handheld film and digital cameras is freely accessible to the global community through the online searchable database at https://eol.jsc.nasa.gov, and offers a useful compliment to traditional ground-commanded sensor data. The dataset includes imagery from the NASA Mercury (1961) through present-day International Space Station (ISS) programs, and currently totals over 2.6 million individual frames. Geographic coverage of the dataset includes land and oceans areas between approximately 52 degrees North and South latitudes, but is spatially and temporally discontinuous. The photographic dataset includes some significant impediments for immediate research, applied, and educational use: commercial RGB films and camera systems with overlapping bandpasses; use of different focal length lenses, unconstrained look angles, and variable spacecraft altitudes; and no native geolocation information. Such factors led to this dataset being underutilized by the community but recent advances in automated and semi-automated image geolocation, image feature classification, and web-based services are adding new value to the astronaut-acquired imagery. A coupled ground software and on-orbit hardware system for the ISS is in development for planned deployment in mid-2017; this system will capture camera pose information for each astronaut photograph to allow automated, full georegistration of the data. The ground system component of the system is currently in use to fully georeference imagery collected in response to International Disaster Charter activations, and the auto-registration procedures are being applied to the extensive historical database of imagery to add value for research and educational purposes. In parallel, machine learning techniques are being applied to automate feature identification and classification throughout the dataset, in order to build descriptive metadata that will improve search capabilities. It is expected that these value additions will increase interest and use of the dataset by the global community.
Stefanov, William L.↗
Cassini's Maneuver Automation Software (MAS) Process: How to Successfully Command 200 Navigation Maneuvers
To keep Cassini on its complex trajectory, more than 200 orbit trim maneuvers (OTMs) have been planned from July 2004 to July 2010. With only a few days between many of these OTMs, the operations process of planning and executing the necessary commands had to be automated. The resulting Maneuver Automation Software (MAS) process minimizes the workforce required for, and maximizes the efficiency of, the maneuver design and uplink activities. The MAS process is a well-organized and logically constructed interface between Cassini's Navigation (NAV), Spacecraft Operations (SCO), and Ground Software teams. Upon delivery of an orbit determination (OD) from NAV, the MAS process can generate a maneuver design and all related uplink and verification products within 30 minutes. To date, all 112 OTMs executed by the Cassini spacecraft have been successful. MAS was even used to successfully design and execute a maneuver while the spacecraft was in safe mode.
Yang, Genevie Velarde↗
Minerva: User-Centered Science Operations Software Capability for Future Human Exploration
In June of 2016, the Biologic Analog Science Associated with Lava Terrains (BASALT) research project conducted its first field deployment, which we call BASALT-1. BASALT-1 consisted of a science-driven field campaign in a volcanic field in Idaho as a simulated human mission to Mars. Scientists and mission operators were provided a suite of ground software tools that we refer to collectively as Minerva to carry out their work. Minerva provides capabilities for traverse planning and route optimization, timeline generation and display, procedure management, execution monitoring, data archiving, visualization, and search. This paper describes the Minerva architecture, constituent components, use cases, and some preliminary findings from the BASALT-1 campaign.
Deans, Matthew↗
Minerva: User-Centered Science Operations Software Capability for Future Human Exploration
In June of 2016, the Biologic Analog Science Associated with Lava Terrains (BASALT) research project conducted its first field deployment, which we call BASALT-1. BASALT-1 consisted of a science-driven field campaign in a volcanic field in Idaho as a simulated human mission to Mars. Scientists and mission operators were provided a suite of ground software tools that we refer to collectively as Minerva to carry out their work. Minerva provides capabilities for traverse planning and route optimization, timeline generation and display, procedure management, execution monitoring, data archiving, visualization, and search. This paper describes the Minerva architecture, constituent components, use cases, and some preliminary findings from the BASALT-1 campaign.
Deans, Matthew↗
Computer based control of the Superfluid Helium On-Orbit Transfer Space Shuttle experiment
Ground software that is being developed for the control of the Superfluid Helium On-Orbit Transfer (SHOOT) project is discussed. Special attention is given to two software development projects for SHOOT support: (1) the SHOOT Command and Monitoring System, which will provide a real-time highly interactive interface for the SHOOT principal investigator to control the experiment and to analyze and display its telemetry; and (2) the SHOOT Aft Flight Deck Operating System, which is comprised of several monitoring programs to give the astronaut mission specialist on-orbit visibility into SHOOT systems, and an intelligent-rule-based system that will control a He transfer without ground intervention. Major accomplishments of the SHOOT project to date include two successful interface tests with the Goddard Space Flight Center developed breadboard electronics and prototype software.
Castellano, T. P.↗
VIPER: Volatiles Investigating Polar Exploration Rover
We will review the technical components of the NASA lunar rover mission, VIPER, with a focus on software components that rely on ROS 2 and Gazebo. We’ll start with an overview of the hardware and software components. Next, we’ll explore some of the custom Gazebo plugins for simulating the rover and the lunar surface. We’ll describe a fault injection framework that was built on ROS 2 parameters and how it is used to simulate hardware faults. Finally, we’ll see how ROS 2 is used as part of the rover ground software.
Jacob Michael Perron↗
Avoiding Human Error in Mission Operations: Cassini Flight Experience
Operating spacecraft is a never-ending challenge and the risk of human error is ever- present. Many missions have been significantly affected by human error on the part of ground controllers. The Cassini mission at Saturn has not been immune to human error, but Cassini operations engineers use tools and follow processes that find and correct most human errors before they reach the spacecraft. What is needed are skilled engineers with good technical knowledge, good interpersonal communications, quality ground software, regular peer reviews, up-to-date procedures, as well as careful attention to detail and the discipline to test and verify all commands that will be sent to the spacecraft. Two areas of special concern are changes to flight software and response to in-flight anomalies. The Cassini team has a lot of practical experience in all these areas and they have found that well-trained engineers with good tools who follow clear procedures can catch most errors before they get into command sequences to be sent to the spacecraft. Finally, having a robust and fault-tolerant spacecraft that allows ground controllers excellent visibility of its condition is the most important way to ensure human error does not compromise the mission.
guidance and control↗
SEXTANT - Station Explorer for X-ray Timing and Navigation Technology
The Station Explorer for X-ray Timing and Navigation Technology (SEXTANT) is a technology demonstration enhancement to the Neutron-star Interior Composition Explorer (NICER) mission, which is scheduled to launch in late 2016 and will be hosted as an externally attached payload on the International Space Station (ISS) via the ExPRESS Logistics Carrier (ELC). During NICER's 18-month baseline science mission to understand ultra-dense matter though observations of neutron stars in the soft X-ray band, SEXTANT will, for the first-time, demonstrate real-time, on-board X-ray pulsar navigation, which is a significant milestone in the quest to establish a GPS-like navigation capability that will be available throughout our Solar System and beyond. Along with NICER, SEXTANT has proceeded through Phase B, Mission Definition, and received numerous refinements in concept of operation, algorithms, flight software, ground system, and ground test capability. NICER/SEXTANT's Phase B work culminated in NASA's confirmation of NICER to Phase C, Design and Development, in March 2014. Recently, NICER/SEXTANT successfully passed its Critical Design Review and SEXTANT received continuation approval in September 2014. In this paper, we describe the X-ray pulsar navigation concept and provide a brief history of previous work, and then summarize the SEXTANT technology demonstration objective, hardware and software components, and development to date.
X-rays↗