Engineering Papers⌕ Search

SEARCH · Engineering Papers

Results for “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.

At least 1,081 records · Page 60

ATM Technology Demonstration-1 Phase II Boeing Configurable Graphical Display (CGD) Software Design Description

This Software Description Document (SDD) captures the design for developing the Flight Interval Management (FIM) system Configurable Graphics Display (CGD) software. Specifically this SDD describes aspects of the Boeing CGD software and the surrounding context and interfaces. It does not describe the Honeywell components of the CGD system. The SDD provides the system overview, architectural design, and detailed design with all the necessary information to implement the Boeing components of the CGD software and integrate them into the CGD subsystem within the larger FIM system. Overall system and CGD system-level requirements are derived from the CGD SRS (in turn derived from the Boeing System Requirements Design Document (SRDD)). Display and look-and-feel requirements are derived from Human Machine Interface (HMI) design documents and working group recommendations. This Boeing CGD SDD is required to support the upcoming Critical Design Review (CDR).

Wilber, George F.↗

Description of the GMAO OSSE for Weather Analysis Software Package: Version 3

The Global Modeling and Assimilation Office (GMAO) at the NASA Goddard Space Flight Center has developed software and products for conducting observing system simulation experiments (OSSEs) for weather analysis applications. Such applications include estimations of potential effects of new observing instruments or data assimilation techniques on improving weather analysis and forecasts. The GMAO software creates simulated observations from nature run (NR) data sets and adds simulated errors to those observations. The algorithms employed are much more sophisticated, adding a much greater degree of realism, compared with OSSE systems currently available elsewhere. The algorithms employed, software designs, and validation procedures are described in this document. Instructions for using the software are also provided.

OSSE↗

Security Vulnerability Profiles of NASA Mission Software: Empirical Analysis of Security Related Bug Reports

NASA develops, runs, and maintains software systems for which security is of vital importance. Therefore, it is becoming an imperative to develop secure systems and extend the current software assurance capabilities to cover information assurance and cybersecurity concerns of NASA missions. The results presented in this report are based on the information provided in the issue tracking systems of one ground mission and one flight mission. The extracted data were used to create three datasets: Ground mission IVV issues, Flight mission IVV issues, and Flight mission Developers issues. In each dataset, we identified the software bugs that are security related and classified them in specific security classes. This information was then used to create the security vulnerability profiles (i.e., to determine how, why, where, and when the security vulnerabilities were introduced) and explore the existence of common trends. The main findings of our work include:- Code related security issues dominated both the Ground and Flight mission IVV security issues, with 95 and 92, respectively. Therefore, enforcing secure coding practices and verification and validation focused on coding errors would be cost effective ways to improve mission's security. (Flight mission Developers issues dataset did not contain data in the Issue Category.)- In both the Ground and Flight mission IVV issues datasets, the majority of security issues (i.e., 91 and 85, respectively) were introduced in the Implementation phase. In most cases, the phase in which the issues were found was the same as the phase in which they were introduced. The most security related issues of the Flight mission Developers issues dataset were found during Code Implementation, Build Integration, and Build Verification; the data on the phase in which these issues were introduced were not available for this dataset.- The location of security related issues, as the location of software issues in general, followed the Pareto principle. Specifically, for all three datasets, from 86 to 88 the security related issues were located in two to four subsystems.- The severity levels of most security issues were moderate, in all three datasets.- Out of 21 primary security classes, five dominated: Exception Management, Memory Access, Other, Risky Values, and Unused Entities. Together, these classes contributed from around 80 to 90 of all security issues in each dataset. This again proves the Pareto principle of uneven distribution of security issues, in this case across CWE classes, and supports the fact that addressing these dominant security classes provides the most cost efficient way to improve missions' security. The findings presented in this report uncovered the security vulnerability profiles and identified the common trends and dominant classes of security issues, which in turn can be used to select the most efficient secure design and coding best practices compiled by the part of the SARP project team associated with the NASA's Johnson Space Center. In addition, these findings provide valuable input to the NASA IVV initiative aimed at identification of the two 25 CWEs of ground and flight missions.

vulnerability↗

Hybridized Agile Software Development of Flight Control Team Tools for International Space Station's Payload Operations Integration Center

Ground systems operations at the National Aeronautics and Space Administration's (NASA) Payload Operations and Integration Function (POIF) is increasing, via the High Operations Tempo (HOT) initiative, its ability to support more science activities with a fourth crew member on the International Space Station (ISS). The Flight Control Team's need to support this increased crew presence mandated the need for a series of software tools to better handle the increasing pace of payload science operations. The overall need was clear from the outset, but the full scope and user experience for each tool, were not as well understood, so establishing a fixed set of initial requirements was not feasible. An Agile Software Development (ASD) paradigm takes advantage of uncertainty, and plans for it, so it was deemed the most appropriate approach to create room for exploring novel concepts, and to mount a rapid and flexible response to inevitiably changing requirements. It facilitated the need for unprecedented collaboration between the Product Team (i.e. users from the Flight Control Team) and the Development Team (i.e. POIC systems engineers, developers, testers). This is a process shift in the development, test, and release of software from one that is prescriptive to one that is adaptive, which is necessary for these tools to have longevity. The application of ASD to the product development lifecycle permitted the timely incorporation of customer feedback, and, allowed for continuous quality improvements. This resulted in a suite of tools that are efficient, user-friendly, and enable POIF ground systems to support the increasing pace of payload science operations. ASD is not as much a set of prescriptive processes as it is a shift in mindset; one that moves from planning against change, to planning for change, thereby iteratively growing software towards user-defined value.

Albers, Cerese M.↗

CHANGO: A Software Tool for Boost Stage Guidance of the Space Launch System Exploration Mission 1

The Day of Launch Initiation Load Update (DOLILU) System is the means by which the Space Launch System (SLS) Vehicle trajectory is designed, verified, and uploaded on the Day of Launch (DOL) in order to ensure a safe flight. Launch vehicles are designed to fly down a narrow angle of attack and sideslip angle corridor in order to keep them within structural load limits. The angle of attack and sideslip angle response to the launch vehicle experiences can vary significantly based upon the winds experienced on the DOL. SLS Boost Stage flight employs an open-loop guidance scheme through Solid Rocket Booster (SRB) separation. In the SLS open-loop scheme, the vehicle will fly a prescribed set of attitudes as a function of the change in altitude since launch. This set of reference attitude values and corresponding altitude reference independent values are designed with ground software using winds measured on the DOL with the goal of minimizing angle of attack and sideslip angle, thereby minimizing related ascent integrated vehicle structural loads. The table of Boost Stage attitude commands as a function of altitude gained since launch is called the chi table. A software tool called CHANGO (Chi Angle Optimizer) designs the Boost Stage chi table which is uploaded to the vehicle’s flight computer and used during ascent by the flight software (FSW). The wind and atmospheric conditions are measured prior to launch and pre-processed to become input to the CHANGO software along with a set of parameters developed in advance of the DOL. CHANGO’s target set consists of the heading and altitude rate at SRB separation determined well before launch by the Program to Optimize Simulated Trajectories (POST). CHANGO consists of a simplified three degree-of-freedom (3-DOF) simulation representing the SLS launch configuration. In general, the launch azimuth is strongly correlated with the heading at SRB separation, and the initial pitchover rate is strongly correlated with the altitude rate at SRB separation. CHANGO uses an adaptation of Powell’s method to vary the initial pitchover rate and launch azimuth to solve a 2-dimentional minimization problem. CHANGO’s trajectory simulation is phase-based, with flight events separating the phases. Each flight phase has different attitude alignment logic. CHANGO’s 3-DOF simulation starts when the vehicle’s thrust-to-weight ratio equals one, and ends at a pre-calculated SRB separation time.

Ahmad, Naeem↗

Agile Approach to Assuring Software for NASA's Orion Spacecraft

Agile software development is prevalent throughout the Government, and NASA is no exception. NASA's Orion spacecraft is being developed to return Astronauts to the moon in the next 5 years, and the role of software in achieving the ambitious mission objectives has expanded dramatically in the last few decades. This presentation is the story of how the Independent Verification and Validation team for Orion adapted to the Agile approach that the Orion Program was using to develop the flight software. Consider attending this session if you are working with software developers utilizing Agile development approaches, or are interested in learning about Agile and Lean principles that could help improve communication within your own team.

Smith, Justin↗

Infusing software assurance research techniques into use

Research in the software engineering community continues to lead to new development techniques that encompass processes, methods and tools. However, a number of obstacles impede their infusion into software deveopment practices. This paper describes an ongoing effort conducted by a software engineering research infusion team established by NASA's Software Engineering Intiative to overcome these obstacles.

Trevino, Luis C.↗

Software for Optical (Laser) Ground Station Monitor and Control ​

Previous NASA laser communication missions have been supported by ground terminals specific to the mission. The Low-Cost Optical Terminal project (LCOT) aims to serve as a commercial off-the-shelf (COTS), reusable, and modular optical ground terminal prototype, provide a blueprint for future optical ground terminals, and enable optical communication experiments with a variety of spacecraft from Low Earth Orbit to lunar orbit. The goal of the internship was the development of LCOT’s Gimbal Monitor and Control (GMC) application, within the LCOT Monitor and Control Subsystem (MCS). Mount control software PWI4 was provided by mount and gimbal vendor Planewave Instruments; developed in Python, GMC integrates and interfaces with PWI4 using third party libraries such as Protobuf and RabbitMQ. As a stand in for the Monitor and Control Subsystem (MCS), a test Graphical User Interface (GUI) was created to send commands to and receive telemetry from the GMC application; these commands and telemetry are sent through the RabbitMQ message bus as Protobuf encoded messages. GMC then interfaces with PWI4 which passes along desired commands and telemetry to and from a vendor provided mount and gimbal simulator. The GMC software developed allows LCOT’s Monitor and Control Subsystem (MCS) to take advantage of the existing mount control software, advancing LCOT’s efforts in the development of the MCS. The MCS and GMC software developed will contribute to LCOT’s goal as a flexible and modular optical ground terminal prototype and blueprint, which supports development towards a potential optical ground terminal network.

space communications↗

Emulation of Core Flight System Applications for Flight Software Development and Validation

The Mars Sample Return (MSR) campaign is an unprecedented attempt in the return of Martian samples back to Earth. The ascent from the surface will be performed by the Mars Ascent Vehicle (MAV), a critical element in the mission that National Aeronautics and Space Administration (NASA) Marshall Space Flight Center (MSFC) is developing. To this end, innovations in flight software development, verification, and validation are occurring. The MAV flight computer will run Core Flight System (cFS), an open-source software environment developed by NASA Goddard Space Flight Center (GSFC). NASA Marshall’s MAV Mission and Fault Management (M&FM) Team has implemented an emulation of two applications of this architecture: Limit Checker and Stored Command. Using an emulation of the functionalities of these applications allows for rapid prototyping of table-based algorithms. Further, M&FM is leveraging an in-house, low-fidelity but high-throughput State Analysis Model (SAM), an integrated MATLAB Stateflow Plant and Software model. This model is run in parallel with the cFS emulation for full flyout testing of the M&FM algorithms, verification of intent of these algorithms, and for future auto-generation of application-ingestible M&FM tables. The tables can then be delivered to the MAV Flight Software (FSW) team in a seamless process, reducing the cost of traditional FSW development and the risk of starting M&FM FSW development at later points in the NASA program life cycle.

Cody Wheeler↗

Clinical Decision Support For Exploration Space Flight: Software Augmentation To Enhance Progressively Earth-Independent Medical Operations

This panel identifies the challenges of supporting medical events in deep space using integrated systems software to augment existing capabilities during increasingly Earth-independent missions where an asynchronous communication environment becomes routine. An interdisciplinary team of software designers, physicians, human factors engineers, and computational modelers applied their respective expertise to develop a roadmap for supporting the crew making medical decisions in more autonomous fashion with time-delayed ground support. The first presentation describes predictive modeling implemented to assist medical system design and address risk reduction using robust clinical decision support software. The second presentation details how operational and environmental challenges guide assumptions and, in turn, by what means requirements for medical decision-making in deep space are derived. The third presentation describes and defines the skills and capabilities an exploration spaceflight medical officer will need to perform effectively during extended-duration spaceflight missions. The fourth presentation covers the potential models and function of the software element for supporting clinical decisions. The final presentation covers how these elements may work together with ground support to provide comprehensive care despite deep space travel's extreme challenges and limitations.

Dana Levin↗

Assuring software cost estimates : is it an oxymoron?

The software industry repeatedly observes cost growth of well over 100% even after decades of cost estimation research and well-known best practices, so “What’s the problem?” In this paper we will provide an overview of the current state of software cost estimation best practice. We then explore whether applying some of the methods used in software assurance might improve the quality of software cost estimates. This paper especially focuses on issues associated with model calibration, estimate review, and the development and documentation of estimates as part of an integrated plan.

Hihn, Jairus↗

Emulation of Core Flight System Applications for Flight Software Development and Validation

The Mars Sample Return (MSR) campaign is an unprecedented attempt in the return of Martian samples back to Earth. The ascent from the surface will be performed by the Mars Ascent Vehicle (MAV), a critical element in the mission that National Aeronautics and Space Administration (NASA) Marshall Space Flight Center (MSFC) is developing. To this end, innovations in flight software development, verification, and validation are occurring. The MAV flight computer will run Core Flight System (cFS), an open-source software environment developed by NASA Goddard Space Flight Center (GSFC). NASA Marshall’s MAV Mission and Fault Management (M&FM) Team has implemented an emulation of two applications of this architecture: Limit Checker and Stored Command. Using an emulation of the functionalities of these applications allows for rapid prototyping of table-based algorithms. Further, M&FM is leveraging an in-house, low-fidelity but high-throughput State Analysis Model (SAM), an integrated MATLAB Stateflow Plant and Software model. This model is run in parallel with the cFS emulation for full flyout testing of the M&FM algorithms, verification of intent of these algorithms, and for future auto-generation of application-ingestible M&FM tables. The tables can then be delivered to the MAV Flight Software (FSW) team in a seamless process, reducing the cost of traditional FSW development and the risk of starting M&FM FSW development at later points in the NASA program life cycle.

Cody Wheeler↗

Adaptive IV&V for Increasingly Complex Software Systems

As NASA software systems continue to innovate, becoming more complex and nondeterministic, the need for the NASA IV&V Program to become systemically adaptive to ensure mission success is paramount. To ensure adaptability within resource constraints, IV&V has developed an agile, risk-based approach to identify, characterize, scope, focus, and prioritize mission assurance activities. This risk based adaptive framework has been applied to trends such as increased reliance on data driven algorithms for safety and mission critical software behavior, use of MBSE in system design, and application of agile principles to embedded software development. The framework is enabled by continuous innovation of new approaches such as software only test beds, assurance design tools, and initiatives that augment IV&V assurance methods with artificial intelligence and machine learning techniques. This presentation will highlight the trends the NASA IV&V Program is seeing, the innovative steps it is taking to address those challenges, and how it is postured to address evolving risk and constantly changing and new technologies.

Wesley W Deadrick↗

Increasing Cognitive Ability/Reserve Using Software – Pilot (ICARUS-Pilot)

BACKGROUND This research study was competitively awarded under the 2022 JSC Innovation Charge Account (ICA) program administered by NASA Johnson Space Center’s Joint Technology Working Group. Study period of performance was May through September 2022, with a maximum allowed procurement budget of $10K. The study sought to quantify and assess the potential benefit of using commercial-off-the-shelf (COTS) cognitive training software to improve cognitive performance in an astronaut-like terrestrial population. METHODS Five volunteer research participants were recruited from the JSC employee population to mimic certain demographic characteristics of the NASA astronaut population (age, education/discipline). Participant cognitive performance was assessed before and after executing eighteen sessions of remote cognitive training executed nominally three times per week using six exercises within an adaptive app-based COTS software package (BrainHQ, Posit Science) on study-provided tablets. Pre- and post-training cognitive performance was measured using internal assessments in BrainHQ as well as Cognition Test Battery (CTB) version ISS B01 v3 (3.0.9-201710021500), an independent software test developed specifically for NASA and used currently in research studies on astronauts. BrainHQ exercises were posited to map well or partially to several CTB sub-tests. Participants provided feedback on their study experience formally via semi-structured interview at the conclusion of testing and informally throughout the study if they encountered issues. RESULTS The enrolled ICARUS-Pilot study participants generally matched Artemis crew demographic characteristics. Four of five participants have completed study training and assessment activities as of the writing of this abstract. These test participants complied well with desired training session frequency and duration yielding an average cumulative active training duration of 15 hours over an average of 45 days; participants showed 78% average improvement in metric performance for the six trained exercises, with an associated overall 33%ile ranking increase against performance of the entire BrainHQ subscribing population for internal pre/post assessment, agreeing with post-study survey self-reported performance increases. CTB overall feedback scoring, not corrected for learning effects, showed an average of 19% performance improvement across its 10 performance measures over the training period for the completed participants. Detailed analyses will be conducted once participant data collection for the study is complete and the resulting dataset is fully populated. DISCUSSION These preliminary results provide a positive trend for the effectiveness of the training approach, but further analysis will be needed to establish significance, investigate far transfer, and suggest the needed participant pool size for subsequent efforts to achieve statistically significant outcomes given similar results. The pilot study has already been helpful by allowing the study team to learn a great deal about the capabilities and limitations of the COTS software package that will be reflected in future proposals along with revised timelines for study execution and test participant management. From participant feedback, one common thread regarding the COTS training was that it felt overly repetitive – future proposals should reassess overall training duration, available levels for each trained exercise, and the behavior of the BrainHQ internal scheduler in determining which exercises should be trained and for how long. If the final analysis of this feasibility study ultimately supports it, the study team will recommend further investigation to fully evaluate this potential countermeasure and optimize its implementation. Future proposals would cite this feasibility study’s outcome and would seek to refine the training protocol and obtain statistically significant results for cognitive performance increases as well as retention data.

cognitive training↗

Increasing Cognitive Ability/Reserve Using Software – Pilot (ICARUS-Pilot)

Background: This research study was competitively awarded under the 2022 JSC Innovation Charge Account (ICA) program administered by NASA Johnson Space Center’s Joint Technology Working Group. Study period of performance was May through September 2022, with a maximum allowed procurement budget of $10K. The study sought to quantify and assess the potential benefit of using commercial-off-the-shelf (COTS) cognitive training software to improve cognitive performance in an astronaut-like terrestrial population. Methods: Five volunteer research participants were recruited from the JSC employee population to mimic certain demographic characteristics of the NASA astronaut population (age, education/discipline). Participant cognitive performance was assessed before and after executing eighteen sessions of remote cognitive training executed nominally three times per week using six exercises within an adaptive app-based COTS software package (BrainHQ, Posit Science) on study-provided tablets. Pre- and post-training cognitive performance was measured using internal assessments in BrainHQ as well as Cognition Test Battery (CTB) version ISS B01 v3 (3.0.9-201710021500), an independent software test developed specifically for NASA and used currently in research studies on astronauts. BrainHQ exercises were posited to map well or partially to several CTB sub-tests. Participants provided feedback on their study experience formally via semi-structured interview at the conclusion of testing and informally throughout the study if they encountered issues. Results: The enrolled ICARUS-Pilot study participants generally matched Artemis crew demographic characteristics. Four of five participants have completed study training and assessment activities as of the writing of this abstract. These test participants complied well with desired training session frequency and duration yielding an average cumulative active training duration of 15 hours over an average of 45 days; participants showed 78% average improvement in metric performance for the six trained exercises, with an associated overall 33%ile ranking increase against performance of the entire BrainHQ subscribing population for internal pre/post assessment, agreeing with post-study survey self-reported performance increases. CTB overall feedback scoring, not corrected for learning effects, showed an average of 19% performance improvement across its 10 performance measures over the training period for the completed participants. Detailed analyses will be conducted once participant data collection for the study is complete and the resulting dataset is fully populated. Discussion: These preliminary results provide a positive trend for the effectiveness of the training approach, but further analysis will be needed to establish significance, investigate far transfer, and suggest the needed participant pool size for subsequent efforts to achieve statistically significant outcomes given similar results. The pilot study has already been helpful by allowing the study team to learn a great deal about the capabilities and limitations of the COTS software package that will be reflected in future proposals along with revised timelines for study execution and test participant management. From participant feedback, one common thread regarding the COTS training was that it felt overly repetitive – future proposals should reassess overall training duration, available levels for each trained exercise, and the behavior of the BrainHQ internal scheduler in determining which exercises should be trained and for how long. If the final analysis of this feasibility study ultimately supports it, the study team will recommend further investigation to fully evaluate this potential countermeasure and optimize its implementation. Future proposals would cite this feasibility study’s outcome and would seek to refine the training protocol and obtain statistically significant results for cognitive performance increases as well as retention data.

cognitive training↗

Advanced Statistical Methods in Spacecraft Flight Software Cost Estimation: Bayesian Regression and Nonlinear Principal Components Analysis to Support System Engineering in the Early Project Lifecycle

This paper provides an overview of the new features and model updates in the upcoming release of the NASA Analogy Software Cost Tool (ASCoT). ASCoT, hosted within the Online NASA Space Estimation Tools (ONSET) on the One NASA Cost Engineering (ONCE) Database, is a web-based tool that provides a suite of estimation tools to support early lifecycle NASA flight software cost analysis. In addition to the traditional parametric flight software costing method COCOMO II, ASCoT contains a Bayesian linear regression to predict total flight software development cost as a function of total spacecraft cost, as well as four analogic methods: k-Nearest Neighbors (kNN) and Clustering models to predict Effort (in work-months) and total source lines of code (SLOC). These methods are designed to work primarily with system-level inputs such as mission type (orbiter, lander, etc.), mission destination (Earth, Inner Planetary, etc.), and the number of instruments and deployables. Nonlinear principal components analysis (NLPCA) is performed to find the principal features of the data composed of both categorical and numerical variables and is necessary prior to defining our analogic methods. Sensitivity analyses and in- and out-of-sample model performance results are presented for the Bayesian CER and the analogic models.

Johnson, James K.↗

Testing Mars 2020 Flight Software and Hardware in the Surface System Development Environment

The Mars 2020 (M2020) Perseverance Rover is NASA's most advanced planetary rover mission to date. It includes a novel Sample Caching Subsystem (SCS) which will collect rock cores for possible future return to Earth, as well as an improved mobility system with enhanced autonomous navigation which will enable it to traverse faster and farther than prior rovers. The development of both systems required extensive flight software and flight hardware testing. To support this testing, we developed the Surface System Development Environment (SSDEV) and used it for a wide variety of testing. SSDEV is a bundled subset of M2020 Flight Software which runs on commercially available Linux computers and can be combined with multiple backend options for simulation and hardware control. The SSDEV architecture enabled our teams to perform much more testing of flight software and flight hardware than would have otherwise been possible. As a secondary benefit, the SSDEV-based test campaigns also helped our teams enter the operations phase of the mission with greater readiness of operations products and tools. In this paper, we summarize the motivation for SSDEV, provide an overview of the SSDEV architecture, list several examples of how SSDEV was used, and summarize lessons learned. SSDEV is not a substitute for integrated testing with flight-like avionics, but it enabled substantially more testing than would have otherwise been possible and also provided some unique benefits. We recommend architectures like SSDEV to future projects that need to perform extensive hardware and software testing using a limited set of flight-like avionics.

Wai, Dennis↗