SEARCH · Search NASA

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.

SourceResearch connectionFrom yearThrough year

Quote a phrase for an exact phrase match. Source license links do not imply unrestricted reuse.

At least 379 records · Page 21

All sources NASA NTRS DOE OSTI

NASA NTRS2014

The TSO Logic and G2 Software Product

This internship assignment for spring 2014 was at John F. Kennedy Space Center (KSC), in NASAs Engineering and Technology (NE) group in support of the Control and Data Systems Division (NE-C) within the Systems Hardware Engineering Branch. (NEC-4) The primary focus was in system integration and benchmarking utilizing two separate computer software products. The first half of this 2014 internship is spent in assisting NE-C4s Electronics and Embedded Systems Engineer, Kelvin Ruiz and fellow intern Scott Ditto with the evaluation of a newly piece of software, called G2. Its developed by the Gensym Corporation and introduced to the group as a tool used in monitoring launch environments. All fellow interns and employees of the G2 group have been working together in order to better understand the significance of the G2 application and how KSC can benefit from its capabilities. The second stage of this Spring project is to assist with an ongoing integration of a benchmarking tool, developed by a group of engineers from a Canadian based organization known as TSO Logic. Guided by NE-C4s Computer Engineer, Allen Villorin, NASA 2014 interns put forth great effort in helping to integrate TSOs software into the Spaceport Processing Systems Development Laboratory (SPSDL) for further testing and evaluating. The TSO Logic group claims that their software is designed for, monitoring and reducing energy consumption at in-house server farms and large data centers, allows data centers to control the power state of servers, without impacting availability or performance and without changes to infrastructure and the focus of the assignment is to test this theory. TSOs Aaron Rallo Founder and CEO, and Chris Tivel CTO, both came to KSC to assist with the installation of their software in the SPSDL laboratory. TSOs software is installed onto 24 individual workstations running three different operating systems. The workstations were divided into three groups of 8 with each group having its own operating system. The first group is comprised of Ubuntus Debian -based Linux the second group is windows 7 Professional and the third group ran Red Hat Linux. The highlight of this portion of the assignment is to compose documentation expressing the overall impression of the software and its capabilities.

TSO Logic↗

NASA NTRS2015

Planning the Unplanned Experiment: Assessing the Efficacy of Standards for Safety Critical Software

We need well-founded means of determining whether software is t for use in safety-critical applications. While software in industries such as aviation has an excellent safety record, the fact that software aws have contributed to deaths illustrates the need for justi ably high con dence in software. It is often argued that software is t for safety-critical use because it conforms to a standard for software in safety-critical systems. But little is known about whether such standards `work.' Reliance upon a standard without knowing whether it works is an experiment; without collecting data to assess the standard, this experiment is unplanned. This paper reports on a workshop intended to explore how standards could practicably be assessed. Planning the Unplanned Experiment: Assessing the Ecacy of Standards for Safety Critical Software (AESSCS) was held on 13 May 2014 in conjunction with the European Dependable Computing Conference (EDCC). We summarize and elaborate on the workshop's discussion of the topic, including both the presented positions and the dialogue that ensued.

Graydon, Patrick J.↗

NASA NTRS2015

NASA Software Cost Estimation Model: An Analogy Based Estimation Model

The cost estimation of software development activities is increasingly critical for large scale integrated projects such as those at DOD and NASA especially as the software systems become larger and more complex. As an example MSL (Mars Scientific Laboratory) developed at the Jet Propulsion Laboratory launched with over 2 million lines of code making it the largest robotic spacecraft ever flown (Based on the size of the software). Software development activities are also notorious for their cost growth, with NASA flight software averaging over 50% cost growth. All across the agency, estimators and analysts are increasingly being tasked to develop reliable cost estimates in support of program planning and execution. While there has been extensive work on improving parametric methods there is very little focus on the use of models based on analogy and clustering algorithms. In this paper we summarize our findings on effort/cost model estimation and model development based on ten years of software effort estimation research using data mining and machine learning methods to develop estimation models based on analogy and clustering. The NASA Software Cost Model performance is evaluated by comparing it to COCOMO II, linear regression, and K- nearest neighbor prediction model performance on the same data set.

Hihn, Jairus↗

NASA NTRSDate not supplied

Risk Reduction through Early Software Prototyping for the Mars Ascent Vehicle

Despite the critical nature flight software plays in the development of spacecraft, software development teams are often brought on to the project after initial requirements definition and design efforts have started, and well after the conceptual design phase has completed. The flight software development team for the Mars Ascent Vehicle has supported the project from project formulation and conceptual design into the formal design and development. This approach has allowed for the development of a robust software prototype that supported risk reduction in numerous areas for the project. Early software prototyping supported decision making in the areas of hardware selection and considerations, software architecture, and simulation requirements. The prototype software actively supported ongoing trade studies and analyses for the project and enable valuable collaboration across multiple subsystems as well as between MSFC and the Jet Propulsion Laboratory. This early development also allowed the team to leverage past projects’ lessons learned to make valuable process improvements.

Stefanie Justice↗

NASA NTRSDate not supplied

Verification and Validation of Elastodynamic Simulation Software for Aerospace Research

Physics-based simulation of nondestructive evaluation (NDE) inspection can help to advance the inspectability and reliability of mechanical systems. However, NDE simulations applicable to non-idealized mechanical components often require large compute domains and long run times. This has prompted development of custom NDE simulation software tailored to high performance computing (HPC) hardware. Verification and validation (V&V) is an integral part of developing this software to ensure implementations are robust and applicable to inspection problems, producing tools and simulations suitable for computational NDE research. This presentation addresses factors common to V&V of several elastodynamic simulation codes applicable to ultrasonic NDE. Examples are drawn from in-house simulation software at NASA Langley Research Center, ranging from ensuring reliability in a 1D heterogeneous media wave equation solver to the V&V needs of 3D cluster-parallel elastodynamic software. Factors specific to a research environment are addressed, where individual simulation results can be as relevant as the software product itself. Distinct facets of V&V are discussed including testing to establish software reliability, employing systematic approaches for consistency with fundamental conservation laws, establishing the numerical stability of algorithms, and demonstrating concurrence with empirical data. This talk also addresses V&V practices for small groups of researchers. This includes establishing resources (e.g. time and personnel) for V&V during project planning to mitigate and control the risk of setbacks. Similarly, we identify ways for individual researchers to use V&V during simulation software development itself to both speed up the development process and reduce incurred technical debt.

NDE↗

NASA NTRSDate not supplied

Exploring Requirements for Software that Learns: A Research Preview

Context & motivation: The development of software that learns has revolutionized how many systems perform. For the most part, these systems are neither safety- nor mission-critical. However, as technology and aspirations advance, there is an increased desire and need for Machine Learning (ML) software in safety- and mission-critical systems, e.g., driverless cars or autonomous space robotics. Problem: In these domains, reliability is crucial and systems have to undergo much scrutiny in terms of both the developed artefacts and the adopted development process. Central to the development of such systems is the elicitation and definition of software requirements that are used to guide the design and verification process. The addition of software components that learn, and the associated capability for unforeseen behavior, makes defining detailed software requirements especially difficult. Principal ideas/results: In this paper, we identify unique characteristics of software requirements that are specific to ML components. To this end, we collect and examine requirements from both academic and industrial sources. Contribution: To the best of our knowledge, this is the first work that presents real-life, industrial patterns of requirements for ML components. Furthermore, this paper identifies key characteristics and provides a foundation for developing a taxonomy of requirements for software that learns.

Probabilistic requirements↗

NASA NTRS2022

Reliability-Aware Requirements Development for Autonomy Software

Autonomy is the ability of a system to make decisions and take actions in the presence of uncertainty. Validating autonomy, therefore, is a matter of validating that the system makes intelligent decisions even when there might be discrepancies between the observed and the expected state of the world as well as when the possible outcome of each of the possible courses of action is uncertain. During the requirements engineering phase, the functions, including those that are required to be autonomous and their expected behavior are specified. However, in the case of autonomous software system, it is challenging to specify all possible scenarios that the software may encounter. Additionally, since autonomous behaviors cannot always be fully predetermined, it is difficult to reason about their completeness and correctness. While these challenges are also faced with non-autonomous system, they are more prevalent for autonomous system due to their complexity and emergent behavior. Our efforts have been three-fold. On one hand, we have developed a goal-based method for requirements decomposition. We have embedded this approach into a higher-level systems engineering framework and then developed methods for decision and reliability analysis within this framework. And finally, we use simulation analysis to validate the more theoretical methods and provide a feedback mechanism. The decision analysis approach (DA) helps in identifying and mitigating the run-time risks, by bringing to the forefront the uncertainties, decisions, interactions, and other factors that may cause autonomous software to make erroneous decisions. The DA framework is used to quantify, for each decision that the software can make, failure risk due to uncertainties. The information about the key decisions and circumstances that can cause autonomous system to make incorrect decisions are used to generate test scenarios to be run in a simulator to ensure that the system can handle error-prone circumstances. The results or outcomes from decisions, based on the simulated scenarios, can then be leveraged to further gain insight of the assured system. We combine a goal-based approach with simulation analysis to facilitate requirements development for autonomous systems and further provide a method for run-time systems level reliability considerations during the autonomous software development process. The DA and the reliability analysis methods provide a formalism for the consideration of uncertainty in the run time decision-making process for autonomous software. This formalism considers the uncertainty involved in the outcome of different courses of action, in terms of performance and cost, as well as a method to consider the system level reliability implications. System level reliability considerations for autonomous software decision making contribute to the satisfaction of the system level goals over the lifecycle of a given mission. We demonstrate our approach using a hypothetical rover path planning example. The requirements for our rover simulator are based on existing literature about Mars rovers and lessons learned from real world observations at JPL. The specifics of the autonomy design for the Mars rovers, that have not been previously cleared for external release, are not used for our demonstrations.

Lindvall, Mikael↗

NASA NTRS2023

Towards Streamlining Auditing for Compliance With Requirements in Open-Source Software at NASA

Context: NASA requires all software to meet several requirements (NPR 7150.2) depending on software criticality. The instantiation of these requirements may vary per project; however, once decided upon, projects must undergo audits to evaluate compliance with these requirements. Aim: We propose that audit effort can be reduced when requirements are realized by leveraging commonly used open-source infrastructure for version control, issue tracking and continuous integration, and the generated records are analyzed using a repository mining software tool to quantify process compliance. Method: We perform a case study in the NASA-funded Copilot project, utilizing Kaiaulu, a repository mining software tool. We define four software compliance metrics based on the Copilot’s requirements, and analyze their impact on source code quality. Results: Our work demonstrates how it is possible to leverage existing open source tools and platforms to facilitate software certification and qualification, and to streamline the auditing process required even when stringent requirements must be enforced. Conclusion: Together, both project and tool can be utilized to visualize project compliance, and metrics can be defined to more easily identify process irregularities to minimize auditing efforts. Project Repository: github.com/Copilot-Language/copilot Tool Repository: github.com/sailuh/kaiaulu

code-quality↗

NASA NTRS2023

Considerations for Software Fault Prevention and Tolerance

Mission or safety-critical spaceflight systems should be developed to both reduce the likelihood of software faults pre-flight and to detect/mitigate the effects of software errors should they occur in-flight. New data is available that categorizes software errors from significant historic spaceflight software incidents with implications and considerations to better develop and design software to both minimize and tolerate these most likely software failures.

Avionics↗

NASA NTRS2005

Lessons Learned Implementing Multi-Mission Sequencing Software

This paper will describe the software and its uses to provide context for its criticality. The different approaches that have been taken to implement the software in a multi-mission format will be outlined. The advantages and disadvantages as well as the lessons learned during development and maintenance of these different architectures will be discussed, Finally. the use of multi-mission software in operations and the lessons learned from using it will be discussed.This paper will provide valuable information to organizations exploring the use of multi-mission software. regardless of whether the change is to minimize spacecraft ground software development time or cost reduction. Similarly. the paper will provide insight into some of the steps that can be taken during software development and operational use that will minimize difficulty later.

software↗

NASA NTRS2014

Evolution of a Reconfigurable Processing Platform for a Next Generation Space Software Defined Radio

The National Aeronautics and Space Administration (NASA)Harris Ka-Band Software Defined Radio (SDR) is the first, fully reprogrammable space-qualified SDR operating in the Ka-Band frequency range. Providing exceptionally higher data communication rates than previously possible, this SDR offers in-orbit reconfiguration, multi-waveform operation, and fast deployment due to its highly modular hardware and software architecture. Currently in operation on the International Space Station (ISS), this new paradigm of reconfigurable technology is enabling experimenters to investigate navigation and networking in the space environment.The modular SDR and the NASA developed Space Telecommunications Radio System (STRS) architecture standard are the basis for Harris reusable, digital signal processing space platform trademarked as AppSTAR. As a result, two new space radio products are a synthetic aperture radar payload and an Automatic Detection Surveillance Broadcast (ADS-B) receiver. In addition, Harris is currently developing many new products similar to the Ka-Band software defined radio for other applications. For NASAs next generation flight Ka-Band radio development, leveraging these advancements could lead to a more robust and more capable software defined radio.The space environment has special considerations different from terrestrial applications that must be considered for any system operated in space. Each space mission has unique requirements that can make these systems unique. These unique requirements can make products that are expensive and limited in reuse. Space systems put a premium on size, weight and power. A key trade is the amount of reconfigurability in a space system. The more reconfigurable the hardware platform, the easier it is to adapt to the platform to the next mission, and this reduces the amount of non-recurring engineering costs. However, the more reconfigurable platforms often use more spacecraft resources. Software has similar considerations to hardware. Having an architecture standard promotes reuse of software and firmware. Space platforms have limited processor capability, which makes the trade on the amount of amount of flexibility paramount.

Telecommunication↗

NASA NTRS2015

Infusing Reliability Techniques into Software Safety Analysis

Software safety analysis for a large software intensive system is always a challenge. Software safety practitioners need to ensure that software related hazards are completely identified, controlled, and tracked. This paper discusses in detail how to incorporate the traditional reliability techniques into the entire software safety analysis process. In addition, this paper addresses how information can be effectively shared between the various practitioners involved in the software safety analyses. The author has successfully applied the approach to several aerospace applications. Examples are provided to illustrate the key steps of the proposed approach.

FTA↗

NASA NTRS2015

Flight Software for the LADEE Mission

The Lunar Atmosphere and Dust Environment Explorer (LADEE) spacecraft was launched on September 6, 2013, and completed its mission on April 17, 2014 with a directed impact to the Lunar Surface. Its primary goals were to examine the lunar atmosphere, measure lunar dust, and to demonstrate high rate laser communications. The LADEE mission was a resounding success, achieving all mission objectives, much of which can be attributed to careful planning and preparation. This paper discusses some of the highlights from the mission, and then discusses the techniques used for developing the onboard Flight Software. A large emphasis for the Flight Software was to develop it within tight schedule and cost constraints. To accomplish this, the Flight Software team leveraged heritage software, used model based development techniques, and utilized an automated test infrastructure. This resulted in the software being delivered on time and within budget. The resulting software was able to meet all system requirements, and had very problems in flight.

LADEE↗

NASA NTRS2016

Quality Attributes for Mission Flight Software: A Reference for Architects

In the international standards for architecture descriptions in systems and software engineering (ISO/IEC/IEEE 42010), "concern" is a primary concept that often manifests itself in relation to the quality attributes or "ilities" that a system is expected to exhibit - qualities such as reliability, security and modifiability. One of the main uses of an architecture description is to serve as a basis for analyzing how well the architecture achieves its quality attributes, and that requires architects to be as precise as possible about what they mean in claiming, for example, that an architecture supports "modifiability." This paper describes a table, generated by NASA's Software Architecture Review Board, which lists fourteen key quality attributes, identifies different important aspects of each quality attribute and considers each aspect in terms of requirements, rationale, evidence, and tactics to achieve the aspect. This quality attribute table is intended to serve as a guide to software architects, software developers, and software architecture reviewers in the domain of mission-critical real-time embedded systems, such as space mission flight software.

Software architecture↗

NASA NTRS2016

Transitioning Autonomous Systems Technology Research to a Flight Software Environment

NASA has developed methods and algorithms for autonomous spacecraft operations,including automated planning and scheduling, fault diagnostics and impact determination,procedure management and display. Making the transition from technology research tooperational flight software requires overcoming significant technical, programmatic andcultural challenges. Technology research is aimed at developing methods that performspecific functions correctly, but the resulting software may not be designed for flightprocessors with limited CPU, memory and network resources, and may not be easilyintegrated into spacecraft flight software. Our objective in the Autonomous Systems andOperations Project is to make significant strides toward the transformation from technologyto operational use. Our focus was twofold: maturing research grade autonomy software intoa flight software environment using broadly accepted languages and tools; and integratingautonomy applications with each other and with representative systems and their data andcommand interfaces. For a target flight software environment, we chose Core FlightSoftware, developed by Goddard Space Flight Center as a common operating systemindependent framework. Our hardware integration environment was provided by theIntegrated Power and Avionics Systems (iPAS) Lab at Johnson Space Center, in whichvarious subsystem development has been conducted to address engineering challenges forthe vehicles and systems required for long-duration missions into the solar system. The iPASand its network of connected facilities provides realistic subsystem hardware or simulationsof spacecraft power, life support, guidance, navigation and control, and command and datahandling subsystems. Interfaces between autonomy applications and the subsystems beingassessed and controlled were developed, assessed and refined. The hardware and softwareenvironment using CFS and the iPAS facility has proven to be a highly flexible and realisticenvironment in which to rapidly integrate applications in an iterative, low cost setting. Usingthe integration environment we have developed, we will turn our focus to performance andsizing analysis to determine the computational requirements for full-scale deployment ofautonomy technology. Scalability of reasoners and the spacecraft models upon which theyoperate, and robustness across the full range of spacecraft conditions and environments willbe explored and improved. We are making significant contributions to the future programsthat will build the spacecraft that will take humans beyond the Earth-Moon system, in whichprogram Systems Engineers will be able to accurately and confidently design in accurate,robust and mature autonomous operations systems.

Flight Software↗

NASA NTRSDate not supplied

Psyche Hardware Abstraction Simulation Environment (PHASE): Development of High-Fidelity Downlink Model for Flight Software Performance Testing

NASA’s Katherine Johnson Independent Verification and Validation (IV&V) Independent Test Capability (ITC) Team develops high fidelity software-only simulations (or “digital-twins”) of NASA’s most critical missions that are then used for software verification and validation (V&V). One such digital-twin simulator nearing maturity is the Psyche Hardware Abstraction Simulation Environment (PHASE). PHASE utilizes an instruction set simulator along with ITC-developed avionics models. PHASE includes a newly-developed model of the telecom hardware with a high-fidelity downlink interface, capable of supporting reconfigurable downlink data rates and transmission modes. The different downlink transmission modes allow more processing to be ceded from software onto the telecom hardware. Thus, we are able to monitor the performance of the downlink software module in the time-partitioned OS and perform more realistic dynamic testing based on software’s resource utilization. This presentation will cover PHASE, avionics modeling, the downlink model, and its usage for flight software performance testing.

modeling↗

NASA NTRS2005

Sequence System Building Blocks: Using a Component Architecture for Sequencing Software

Over the last few years software engineering has made significant strides in making more flexible architectures and designs possible. However, at the same time, spacecraft have become more complex and flight software has become more sophisticated. Typically spacecraft are often one-of-a-kind entities that have different hardware designs, different capabilities, different instruments, etc. Ground software has become more complex and operations teams have had to learn a myriad of tools that all have different user interfaces and represent data in different ways. At Jet Propulsion Laboratory (JPL) these themes have collided to require an new approach to producing ground system software. Two different groups have been looking at tackling this particular problem. One group is working for the JPL Mars Technology Program in the Mars Science Laboratory (MSL) Focused Technology area. The other group is the JPL Multi-Mission Planning and Sequencing Group . The major concept driving these two approaches on a similar path is to provide software that can be a more cohesive flexible system that provides a act of planning and sequencing system of services. This paper describes the efforts that have been made to date to create a unified approach from these disparate groups.

flexible architectures↗

NASA NTRS1973

Analyses of requirements for computer control and data processing experiment subsystems: Image data processing system (IDAPS) software description (7094 version), volume 2

A description of each of the software modules of the Image Data Processing System (IDAPS) is presented. The changes in the software modules are the result of additions to the application software of the system and an upgrade of the IBM 7094 Mod(1) computer to a 1301 disk storage configuration. Necessary information about IDAPS sofware is supplied to the computer programmer who desires to make changes in the software system or who desires to use portions of the software outside of the IDAPS system. Each software module is documented with: module name, purpose, usage, common block(s) description, method (algorithm of subroutine) flow diagram (if needed), subroutines called, and storage requirements.

Source record↗