Results for “Team software development” — Page 21

NASA NTRS2019

Bumper: A Tool for Analyzing Spacecraft Micrometeoroid and Orbital Debris Risk

“Bumper” is NASA’s computer program for analyzing spacecraft micrometeoroid and orbital debris (MMOD) risk. Bumper was developed in the late-1980s and has been continuously used and maintained since. The user base has grown from a few government entities to now include numerous commercial entities as well. The NASA Johnson Space Center (JSC) Hypervelocity Impact Technology (HVIT) Team is responsible for all aspects of the Bumper software. Bumper has been used to characterize MMOD risk on hundreds of spacecraft. All of the International Space Station (ISS) modules, visiting vehicles and numerous external components and systems have been analyzed. Bumper was used to analyze each of the Space Shuttle missions since STS-50. The Orion Multi-Purpose Crew Vehicle (MPCV) MMOD shielding is being developed using Bumper as well. Bumper has also been used on numerous telescopes (Hubble, James Webb, and Fermi Gamma-ray Space Telescopes), scientific probes (Stardust, New Horizons, Parker Solar Probe), and Earth observation satellites (Landsat, Joint Polar Satellite System). Bumper is also being used to analyze the micrometeoroid risk and support design of the Deep Space Gateway (DSG) and Mars Sample Return (MSR) missions. The HVIT Bumper Configuration Control Board (CCB) ensures that all changes to the code are approved, reviewed, and documented. Most of the changes are made to add new MMOD damage “ballistic limit equations” (BLEs). BLEs are typically added in response to completion of a hypervelocity impact (HVI) test series and development of an associated BLE. Other less frequent changes include updates of the debris or meteoroid environment models, feature enhancements, and feature retirement. Some BLEs are commercially sensitive and/or proprietary, so the CCB also manages code user-version control and software distribution. The current version – “Bumper 3” – is a FORTRAN executable that utilizes a 64-bit architecture. Bumper 3 has numerous features that make it a powerful tool for analyzing spacecraft MMOD risk. Bumper uses the latest orbital debris and micrometeoroid environment models. Bumper also easily processes large spacecraft geometry models, recognizes hidden surfaces, permits BLE assignment by name or number, and conducts quality checks of the spacecraft geometry model. Bumper 3 can also be used to estimate the effects of particle penetration through thin, high-standoff distance hardware components such as solar arrays and radiators. This is done using a special HVIT-developed technique know as the “3-Part Analysis.” The paper introduces the Bumper 3 MMOD risk analysis code and provides an example MMOD risk assessment showing Bumper’s role in the overall MMOD protection design process.

Lear, Dana M.↗

NASA NTRS2020

A ROS-based Simulator for Testing the Enhanced Autonomous Navigation of the Mars 2020 Rover

In order to achieve the ambitious objectives of the Mars 2020 (M2020) mission, in particular the ability to autonomously traverse more challenging terrains more efficiently, new surface mobility software was developed for Enhanced Navigation (ENav). That decision was made early in the project, before most of the new surface flight software (FSW) existed, which created a need for a separate framework where the new navigation algorithms could be quickly prototyped and tested, before more realistic FSW-based testbeds became available. The JPL robotics team chose the Robot Operating System [1] (ROS) as the environment in which to test the new ENav algorithms. This made it possible to write the algorithms in the C language required by the FSW, so they could be directly ported over to the flight module later on, while leveraging all the C++ libraries and tools provided by ROS for simulation and testing. The ENav algorithms were developed as a separate C library, and stubs were used to replace any FSW-specific code, such as Event Reporting (EVRs) and data products (DPs). A ROS simulator was developed to generate a rich set of varied 3D terrains representative of the candidate Mars landing sites and simulate the physics of the rover motion, the point cloud perceived by the rover’s stereo vision system, and the new thinking-while-driving (TWD) navigation logic which directs the rover to drive autonomously to user-specified waypoints. To simulate the rover motion and perception, a ROS node was developed that uses a software library called HyperDrive Sim (HDSim), which is a wrapper for the Rover Sequencing and Visualization Program [2] (RSVP). That library provides roverterrain settling, realistic slip modelling, and camera rendering capability based on the rover’s NavCam machine vision models. To simulate the navigation logic, a ROS node was created that initializes and runs the ENav algorithms in a way that mimics the FSW execution, while also providing the capability to load and replay data products, including re-running the recorded inputs through the ENav algorithms for testing. An engineering Graphical User Interface (GUI) was also developed to visualize various elements, such as the rover pose during the drive, the simulated and perceived terrain, the selected local and global paths to the goal, the evaluated candidate paths and the reasons why they were rejected, the keep-in and keep-out zones (KIOZs), etc. Finally, an advanced Monte Carlo (MC) framework that can run many simulations in parallel on the Cloud and automatically generate reports that capture the key ENav performance metrics was developed to evaluate the system in a statisticallymeaningful way. This paper provides an overview of the ROSbased simulator used for testing the M2020 ENav algorithms.

Toupet, Olivier↗

NASA NTRS2022

Making or Breaking a Rover: System Engineering Parameters On-Board the Mars 2020 Perseverance Rover

On February 18, 2021, Perseverance, NASA’s Jet Propulsion Laboratory’s (JPL’s) Mars 2020 Rover, successfully landed on Mars with all systems nominal, despite the risk surrounding the over 200,000 internal flight parameters that had to be properly configured. The Perseverance team defines these parameters as software variables that are configurable, commandable and retrievable from Earth. In 2015, the Mars 2020 project leaders focused on improving systems engineering of parameters based on their experiences from parameter management on previous Mars rovers (Curiosity, Opportunity, Spirit, and Pathfinder) and parameter failures of past missions, such as the mission-ending parameter of the Mars Climate Orbiter. The new rigorous development process allowed for efficient certification and effective implementation of the parameters, allowing the rover to approach and land on the red planet (the most challenging phase of the mission) with zero parameter issues. Although successful, the Perseverance team learned many lessons for how to better manage parameters for the continued surface operations of the Mars 2020 mission and future missions. This paper will discuss eight parameter-management topics for the Perseverance Mission. The first is parameter definition: how we define parameters on our mission, where they are physically located on the vehicle, and why we have so many of them. The second topic is the updated parameter flight software module from Curiosity, including details on the 99% reduction in parameter commands, new bulk configuration capabilities, and improved parameter traceability. The third topic is parameter selection for different mission phases; this includes improving and tweaking our preferred parameter settings until they become certification candidates and managing parameter configurations based on test venue throughout the mission life cycle. The fourth topic is our flight certification process; this includes certification of flight values for four different epochs in the mission: Launch, Entry Decent and Landing (EDL) - 6days, Landing + 5 Sols (Martian Days, still on Cruise Flight Software), and once are on Surface Flight Software (FSW). The fifth topic covers in-flight command implementation, along with details on testing, validation, and verification of those commands. In the sixth section, we will explain our use of open-source management tools, including how we used GitHub for version control and management approvals. The seventh topic will describe the ground tools used in operations, including capabilities of the in-house built tool called Parasol. The eighth and final topic will dig into lessons learned for improving parameter management in the future of this mission and others.

Roth, Brian↗

NASA NTRS2022

Making or Breaking a Rover- Systems Engineering Parameters On-Board the Mars 2020 Perseverance Rover

On February 18, 2021, Perseverance, NASA’s Jet Propulsion Laboratory’s (JPL’s) Mars 2020 Rover, successfully landed on Mars with all systems nominal, despite the risk surrounding the over 200,000 internal flight parameters that had to be properly configured. The Perseverance team defines these parameters as software variables that are configurable, commandable and retrievable from Earth. In 2015, the Mars 2020 project leaders focused on improving systems engineering of parameters based on their experiences from parameter management on previous Mars rovers (Curiosity, Opportunity, Spirit, and Pathfinder) and parameter failures of past missions, such as the mission-ending parameter of the Mars Climate Orbiter. The new rigorous development process allowed for efficient certification and effective implementation of the parameters, allowing the rover to approach and land on the red planet (the most challenging phase of the mission) with zero parameter issues. Although successful, the Perseverance team learned many lessons for how to better manage parameters for the continued surface operations of the Mars 2020 mission and future missions. This paper will discuss eight parameter-management topics for the Perseverance Mission. The first is parameter definition: how we define parameters on our mission, where they are physically located on the vehicle, and why we have so many of them. The second topic is the updated parameter flight software module from Curiosity, including details on the 99% reduction in parameter commands, new bulk configuration capabilities, and improved parameter traceability. The third topic is parameter selection for different mission phases; this includes improving and tweaking our preferred parameter settings until they become certification candidates and managing parameter configurations based on test venue throughout the mission life cycle. The fourth topic is our flight certification process; this includes certification of flight values for four different epochs in the mission: Launch, Entry Decent and Landing (EDL) - 6days, Landing + 5 Sols (Martian Days, still on Cruise Flight Software), and once are on Surface Flight Software (FSW). The fifth topic covers in-flight command implementation, along with details on testing, validation, and verification of those commands. In the sixth section, we will explain our use of open-source management tools, including how we used GitHub for version control and management approvals. The seventh topic will describe the ground tools used in operations, including capabilities of the in-house built tool called Parasol. The eighth and final topic will dig into lessons learned for improving parameter management in the future of this mission and others.

Roth, Brian↗

NASA NTRS2004

Pressure and Temperature Sensitive Paint Field System

This report documents the Pressure and Temperature Sensitive Paint Field System that is used to provide global surface pressure and temperature measurements on models tested in Langley wind tunnels. The system was developed and is maintained by Global Surface Measurements Team personnel of the Data Acquisition and Information Management Branch in the Research Facilities Services Competency. Descriptions of the system hardware and software are presented and operational procedures are detailed.

Sprinkle, Danny R.↗

NASA NTRS2011

Cassini Tour Atlas Automated Generation

During the Cassini spacecraft s cruise phase and nominal mission, the Cassini Science Planning Team developed and maintained an online database of geometric and timing information called the Cassini Tour Atlas. The Tour Atlas consisted of several hundreds of megabytes of EVENTS mission planning software outputs, tables, plots, and images used by mission scientists for observation planning. Each time the nominal mission trajectory was altered or tweaked, a new Tour Atlas had to be regenerated manually. In the early phases of Cassini s Equinox Mission planning, an a priori estimate suggested that mission tour designers would develop approximately 30 candidate tours within a short period of time. So that Cassini scientists could properly analyze the science opportunities in each candidate tour quickly and thoroughly so that the optimal series of orbits for science return could be selected, a separate Tour Atlas was required for each trajectory. The task of manually generating the number of trajectory analyses in the allotted time would have been impossible, so the entire task was automated using code written in five different programming languages. This software automates the generation of the Cassini Tour Atlas database. It performs with one UNIX command what previously took a day or two of human labor.

Grazier, Kevin R.↗

NASA NTRS2013

Flight Planning Branch NASA Co-op Tour

This semester I worked with the Flight Planning Branch at the NASA Johnson Space Center. I learned about the different aspects of flight planning for the International Space Station as well as the software that is used internally and ISSLive! which is used to help educate the public on the space program. I had the opportunity to do on the job training in the Mission Control Center with the planning team. I transferred old timeline records from the planning team's old software to the new software in order to preserve the data for the future when the software is retired. I learned about the operations of the International Space Station, the importance of good communication between the different parts of the planning team, and enrolled in professional development classes as well as technical classes to learn about the space station.

Marr, Aja M.↗

NASA NTRS2017

Collaborative Data Publication Utilizing the Open Data Repository's Data Publisher

For small communities in multidisciplinary fields such as astrobiology, publishing and sharing data can be challenging. While large, homogenous fields often have repositories and existing data standards, small groups of independent researchers have few options for publishing data that can be utilized within their community. In conjunction with teams at NASA Ames and the University of Arizona, a number of pilot studies are being conducted to assess the needs of these research groups and to guide the software development so that it allows them to publish and share their data collaboratively.

Human-readable interfaces↗

NASA NTRSDate not supplied

Wikipedia for SmallSats: The SSRI Knowledge Base

The Small Satellite Reliability Initiative (SSRI), in conjunction with NASA’s Small Spacecraft Systems Virtual Institute (S3VI), has developed the SSRI Knowledge Base: a comprehensive, publicly available online tool that aims to improve mission confidence for future small spacecraft. This tool provides vetted, high-quality sources of information on key elements of a successful mission. This content includes best practices and lessons learned from previous missions and Knowledge Base “resources”. These resources include publicly available SSRI-generated content in addition to existing guides, publications, standards, software tools, websites, and books. Acknowledging the constant increase and varied sources of small spacecraft knowledge, along with the value and depth of experience that exists beyond any single development team, the SSRI Knowledge Base is designed to be an open, collaborative platform. User participation is essential to the refinement and growth of this tool. Therefore, users are encouraged to rate resources and to contribute content. The SSRI Knowledge Base is hosted at https://www.nasa.gov/smallsat-institute/ssri-knowledge-base. This webinar will discuss the motivation for and development of the SSRI Knowledge Base, demonstrate the existing tool, and outline plans for further development.

SmallSats↗

NASA NTRS1997

Steady-State Cycle Deck Launcher Developed for Numerical Propulsion System Simulation

One of the objectives of NASA's High Performance Computing and Communications Program's (HPCCP) Numerical Propulsion System Simulation (NPSS) is to reduce the time and cost of generating aerothermal numerical representations of engines, called customer decks. These customer decks, which are delivered to airframe companies by various U.S. engine companies, numerically characterize an engine's performance as defined by the particular U.S. airframe manufacturer. Until recently, all numerical models were provided with a Fortran-compatible interface in compliance with the Society of Automotive Engineers (SAE) document AS681F, and data communication was performed via a standard, labeled common structure in compliance with AS681F. Recently, the SAE committee began to develop a new standard: AS681G. AS681G addresses multiple language requirements for customer decks along with alternative data communication techniques. Along with the SAE committee, the NPSS Steady-State Cycle Deck project team developed a standard Application Program Interface (API) supported by a graphical user interface. This work will result in Aerospace Recommended Practice 4868 (ARP4868). The Steady-State Cycle Deck work was validated against the Energy Efficient Engine customer deck, which is publicly available. The Energy Efficient Engine wrapper was used not only to validate ARP4868 but also to demonstrate how to wrap an existing customer deck. The graphical user interface for the Steady-State Cycle Deck facilitates the use of the new standard and makes it easier to design and analyze a customer deck. This software was developed following I. Jacobson's Object-Oriented Design methodology and is implemented in C++. The AS681G standard will establish a common generic interface for U.S. engine companies and airframe manufacturers. This will lead to more accurate cycle models, quicker model generation, and faster validation leading to specifications. The standard will facilitate cooperative work between industry and NASA. The NPSS Steady-State Cycle Deck team released a batch version of the Steady-State Cycle Deck in March 1996. Version 1.1 was released in June 1996. During fiscal 1997, NPSS accepted enhancements and modifications to the Steady-State Cycle Deck launcher. Consistent with NPSS' commercialization plan, these modifications will be done by a third party that can provide long-term software support.

VanDrei, Donald E.↗

NASA NTRSDate not supplied

COCPIT: Collaborative Activity Planning Software for Mars Perseverance Rover

Since landing on the Martian surface, the Perseverance rover has relied on a distributed team to generate commands for exploring its new environment each sol(Martian day). The team uses a complex suite of software tools to accomplish this challenging task in time for the next window of opportunity to send commands to the rover. A key piece of this software ecosystem is COCPIT (Component-based Campaign Planning, Implementation, and Tactical). COCPIT is part of the next generation of planning and scheduling software tools developed by NASA's Jet Propulsion Laboratory in partnership with NASA's Ames Research Center. COCPIT is a web-based application that allows users to collaboratively view and update the Perseverance rover's activity plans, continuously verify that the plan satisfies constraints, assign targets for directing scientific instruments, document science intent, and model power and data resources. Mars Surface Operations requires diverse expertise from team members within the Engineering, Science, Robotic, and Instrument Operations groups, distributed across North America and Europe. In order to improve efficiency and reduce risk, all teams are able to review and edit their activities simultaneously and see the effects on the plan in its entirety. As part of the Ground Data System (GDS) tool suite, COCPIT is responsible for the activity plan. It provides specialized views that allow operators to understand where there may be room for additional observations, see whether any planning constraints are being violated, and confirm that energy usage and data generation are within the defined limits. It contains details such as which filters a camera will use for a given observation, what the resolution of the images should be, where to store the data onboard, and how long the observation is expected to take. It predicts when specific data will be downlinked from the rover to a passing orbiter, so that the team knows when to expect that data on Earth for evaluation in future planning. Ultimately the information from the COCPIT plan is translated to sequences that will be bundled and radiated to Perseverance for execution. The COCPIT tool is used throughout all planning phases.

activity planning↗

NASA NTRSDate not supplied

COCPIT: Collaborative Activity Planning Software for Mars Perseverance Rover

Since landing on the Martian surface, the Perseverance rover has relied on a distributed team to generate commands for exploring its new environment each sol(Martian day). The team uses a complex suite of software tools to accomplish this challenging task in time for the next window of opportunity to send commands to the rover. A key piece of this software ecosystem is COCPIT (Component-based Campaign Planning, Implementation, and Tactical). COCPIT is part of the next generation of planning and scheduling software tools developed by NASA's Jet Propulsion Laboratory in partnership with NASA's Ames Research Center. COCPIT is a web-based application that allows users to collaboratively view and update the Perseverance rover's activity plans, continuously verify that the plan satisfies constraints, assign targets for directing scientific instruments, document science intent, and model power and data resources. Mars Surface Operations requires diverse expertise from team members within the Engineering, Science, Robotic, and Instrument Operations groups, distributed across North America and Europe. In order to improve efficiency and reduce risk, all teams are able to review and edit their activities simultaneously and see the effects on the plan in its entirety. As part of the Ground Data System (GDS) tool suite, COCPIT is responsible for the activity plan. It provides specialized views that allow operators to understand where there may be room for additional observations, see whether any planning constraints are being violated, and confirm that energy usage and data generation are within the defined limits. It contains details such as which filters a camera will use for a given observation, what the resolution of the images should be, where to store the data onboard, and how long the observation is expected to take. It predicts when specific data will be downlinked from the rover to a passing orbiter, so that the team knows when to expect that data on Earth for evaluation in future planning. Ultimately the information from the COCPIT plan is translated to sequences that will be bundled and radiated to Perseverance for execution. The COCPIT tool is used throughout all planning phases.

activity planning↗

NASA NTRS2022

COCPIT: Collaborative Activity Planning Software for Mars Perseverance Rover

Since landing on the Martian surface, the Perseverance rover has relied on a distributed team to generate commands for exploring its new environment each sol (Martian day). The team uses a complex suite of software tools to accomplish this challenging task in time for the next window of opportunity to send commands to the rover. A key piece of this software ecosystem is COCPIT (Component-based Campaign Planning, Implementation, and Tactical). COCPIT is part of the next generation of planning and scheduling software tools developed by NASA's Jet Propulsion Laboratory in partnership with NASA's Ames Research Center. COCPIT is a web-based application that allows users to collaboratively view and update the Perseverance rover's activity plans, continuously verify that the plan satisfies constraints, assign targets for directing scientific instruments, document science intent, and model power and data resources. Mars Surface Operations requires diverse expertise from team members within the Engineering, Science, Robotic, and Instrument Operations groups, distributed across North America and Europe. In order to improve efficiency and reduce risk, all teams are able to review and edit their activities simultaneously and see the effects on the plan in its entirety. As part of the Ground Data System (GDS) tool suite, COCPIT is responsible for the activity plan. It provides specialized views that allow operators to understand where there may be room for additional observations, see whether any planning constraints are being violated, and confirm that energy usage and data generation are within the defined limits. It contains details such as which filters a camera will use for a given observation, what the resolution of the images should be, where to store the data onboard, and how long the observation is expected to take. It predicts when specific data will be downlinked from the rover to a passing orbiter, so that the team knows when to expect that data on Earth for evaluation in future planning. Ultimately the information from the COCPIT plan is translated to sequences that will be bundled and radiated to Perseverance for execution. The COCPIT tool is used throughout all planning phases.

Kanefsky, Bob↗

NASA NTRS1990

Prelaunch processing scientific payloads since Challenger - Lessons learned exercise

The 'lessons learned' process that follows each NASA payload-processing operation is described with attention given to the development of a knowledge base from the results. The process is based on the subjective evaluation of operations problems by test-team members following a mission. The lessons learned from four Space Shuttle missions - STS-26R, -29R, -30R, and -30 - are examined with categorizations of incidents which is based on operational, documentation, hardware, and software categories. Recommendations for ways to address the incidents are categorized similarly, with operational categories such as admonitory, documentation modifications, and support changes. A basic numerical dataset is developed based on the results, and the data show that STS-26R had the highest number of incidents. The process is found to be an effective educational tool in payload-processing operations because it disseminates key individual experiences.

Schuiling, R. L.↗

NASA NTRS2003

Developing of a New Atmospheric Ionizing Radiation (AIR) Model

As a result of the research leading to the 1998 AIR workshop and the subsequent analysis, the neutron issues posed by Foelsche et al. and further analyzed by Hajnal have been adequately resolved. We are now engaged in developing a new atmospheric ionizing radiation (AIR) model for use in epidemiological studies and air transportation safety assessment. A team was formed to examine a promising code using the basic FLUKA software but with modifications to allow multiple charged ion breakup effects. A limited dataset of the ER-2 measurements and other cosmic ray data will be used to evaluate the use of this code.

Clem, John M.↗

NASA NTRS2014

Defining Reliability and Robustness from a Human Factors Perspective

A human factors team was tasked with assessing best practices for developing a crewed space vehicle that is both reliable and robust. The team identified two broad dimensions of human factors are relevant to system design. Namely, the attributes of the product, and the processes used to develop the product. The “product” includes hardware, software, documentation, training systems, and procedures throughout all phases of the system life, including construction, testing, operation and maintenance. Three product attributes relevant to robustness are the extent to which task demands are within human capabilities, the capacity of the system to cope with unanticipated human actions, and the ability of the system to make use of unique human capabilities during non-routine situations. The “process” dimension of human factors relates to the activities that start in the early stages of design, and continue throughout the life of the system. There are, of course, no guarantees that a formal consideration of human factors throughout the design process will identify all the relevant human issues. In the absence of such a consideration, however, problems are virtually assured.

Hobbs, Alan↗

NASA NTRS2018

Verifying Interfaces and Generating Interface Control Documents for the Alignment and Phasing Subsystem of the Thirty Meter Telescope from a System Model in SysML

This paper presents a novel method for verifying interfaces and generating interface control documents (ICDs) from a system model in SysMLTM. In systems and software engineering, ICDs are key artifacts that specify the interface(s) to a system or subsystem, and are used to control the documentation of these interfaces. ICDs enable independent teams to develop connecting systems that use the speciﬁed interfaces. In the context of the Thirty Meter Telescope (TMT), interface control documents also act as contracts for delivered subsystems. The Alignment and Phasing system (APS) is one such subsystem. APS is required to implement a particular interface, and formulates requirements for the interfaces to be provided by other components of TMT that interface with APS. As the design of APS matures, these interfaces are frequently reﬁned, making it necessary for related ICDs to be updated. In current systems engineering practice, ICDs are maintained manually. This manual maintenance can lead to a loss in integrity and accuracy of the documents over time, resulting in the documents no longer reﬂecting the actual state of the interfaces of a system. We show how a system model in SysMLTM can be used to generate ICDs automatically. The method is demonstrated through application to interface control documents pertaining to APS. Speciﬁcally, we apply the method to the interface of APS to the primary mirror control system (M1CS) and of APS to the Telescope Control System (TCS). We evaluate the newly introduced method through application to two case studies.

Troy, Mitchell↗

NASA NTRS2007

Preliminary Structural Sizing and Alternative Material Trade Study of CEV Crew Module

This paper presents the results of a preliminary structural sizing and alternate material trade study for NASA s Crew Exploration Vehicle (CEV) Crew Module (CM). This critical CEV component will house the astronauts during ascent, docking with the International Space Station, reentry, and landing. The alternate material design study considers three materials beyond the standard metallic (aluminum alloy) design that resulted from an earlier NASA Smart Buyer Team analysis. These materials are graphite/epoxy composite laminates, discontinuously reinforced SiC/Al (DRA) composites, and a novel integrated panel material/concept known as WebCore. Using the HyperSizer (Collier Research and Development Corporation) structural sizing software and NASTRAN finite element analysis code, a comparison is made among these materials for the three composite CM concepts considered by the 2006 NASA Engineering and Safety Center Composite Crew Module project.

Bednarcyk, Brett A.↗