Engineering Papers⌕ Search

SEARCH · Engineering Papers

Results for “software development”

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 541 records · Page 30
All sourcesNASA NTRSDOE OSTI
NASA NTRS2018

NOS3: NASA Operational Simulator for Small Satellites

The NASA Operational Simulator for Small Satellites (NOS3) is a suite of open-source software tools to aid in areas such as software development, integration & test (I&T), mission operations/training, verification and validation (V&V), and software systems check-out. NOS3 provides a software development environment, a multi-target build system, operational interface/ground software, dynamics and environment simulations, and software-based hardware models. NOS3 has just recently been open-sourced by NASA and is available for immediate use. It enables the development of flight software (FSW) early in the project life cycle when hardware availability is limited. Small satellite development suffers from extensive lead times on many of the commercial-off-the-shelf (COTS) components as well as limited funding for engineering test units (ETUs). To alleviate the need to provide a hardware test-bed for each developer/tester, NOS3 hardware models are based upon characteristic data or manufacturer's data sheets for each individual component. The NOS3 hardware models' fidelity is such that FSW executes unaware that physical hardware is not present. This allows FSW binaries to be compiled for both the simulation environment and the flight computer without changing the FSW source code. For hardware models that provide data which is dependent upon the environment and spacecraft dynamics, such as a GPS receiver or magnetometer, an open-source tool from NASA GSFC (42 Spacecraft Simulator) is used to provide the necessary data. The underlying infrastructure used to transfer messages between FSW and the hardware models can also be used to monitor, intercept, and inject messages, which has proven to be beneficial for V&V of larger missions such as James Webb Space Telescope (JWST). As hardware is selected and becomes available, drivers can be added to the NOS3 environment to enable hardware-in-the-loop (HWIL) testing. When strict time synchronization is not vital, any number of combinations of hardware components and software-based models can be tested. NOS3 was actively used for FSW development and component testing of the Simulation-to-Flight 1 (STF-1) CubeSat and the Lunar IceCube CubeSat. As NOS3 matures, hardware models have been added for common small satellite components such as GPS receivers, electrical power systems and batteries, and antenna systems.

Suder, Mark↗
NASA NTRS2016

NASA Operational Simulator for Small Satellites: Tools for Software Based Validation and Verification of Small Satellites

The NASA Operational Simulator for Small Satellites (NOS3) is a suite of tools to aid in areas such as software development, integration test (IT), mission operations training, verification and validation (VV), and software systems check-out. NOS3 provides a software development environment, a multi-target build system, an operator interface-ground station, dynamics and environment simulations, and software-based hardware models. NOS3 enables the development of flight software (FSW) early in the project life cycle, when access to hardware is typically not available. For small satellites there are extensive lead times on many of the commercial-off-the-shelf (COTS) components as well as limited funding for engineering test units (ETU). Considering the difficulty of providing a hardware test-bed to each developer tester, hardware models are modeled based upon characteristic data or manufacturers data sheets for each individual component. The fidelity of each hardware models is such that FSW executes unaware that physical hardware is not present. This allows binaries to be compiled for both the simulation environment, and the flight computer, without changing the FSW source code. For hardware models that provide data dependent on the environment, such as a GPS receiver or magnetometer, an open-source tool from NASA GSFC (42 Spacecraft Simulation) is used to provide the necessary data. The underlying infrastructure used to transfer messages between FSW and the hardware models can also be used to monitor, intercept, and inject messages, which has proven to be beneficial for VV of larger missions such as James Webb Space Telescope (JWST). As hardware is procured, drivers can be added to the environment to enable hardware-in-the-loop (HWIL) testing. When strict time synchronization is not vital, any number of combinations of hardware components and software-based models can be tested. The open-source operator interface used in NOS3 is COSMOS from Ball Aerospace. For testing, plug-ins are implemented in COSMOS to control the NOS3 simulations, while the command and telemetry tools available in COSMOS are used to communicate with FSW. NOS3 is actively being used for FSW development and component testing of the Simulation-to-Flight 1 (STF-1) CubeSat. As NOS3 matures, hardware models have been added for common CubeSat components such as Novatel GPS receivers, ClydeSpace electrical power systems and batteries, ISISpace antenna systems, etc. In the future, NASA IVV plans to distribute NOS3 to other CubeSat developers and release the suite to the open-source community.

Verification↗
DOE OSTI2014

System Advisor Model, SAM 2014.1.14: General Description

This document describes the capabilities of the U.S. Department of Energy and National Renewable Energy Laboratory's System Advisor Model (SAM), Version 2013.9.20, released on September 9, 2013. SAM is a computer model that calculates performance and financial metrics of renewable energy systems. Project developers, policy makers, equipment manufacturers, and researchers use graphs and tables of SAM results in the process of evaluating financial, technology, and incentive options for renewable energy projects. SAM simulates the performance of photovoltaic, concentrating solar power, solar water heating, wind, geothermal, biomass, and conventional power systems. The financial model can represent financial structures for projects that either buy and sell electricity at retail rates (residential and commercial) or sell electricity at a price determined in a power purchase agreement (utility). SAM's advanced simulation options facilitate parametric and sensitivity analyses, and statistical analysis capabilities are available for Monte Carlo simulation and weather variability (P50/P90) studies. SAM can also read input variables from Microsoft Excel worksheets. For software developers, the SAM software development kit (SDK) makes it possible to use SAM simulation modules in their applications written in C/C++, C#, Java, Python, and MATLAB. NREL provides both SAM and the SDK as free downloads at http://sam.nrel.gov. Technical support and more information about the software are available on the website.

14 SOLAR ENERGY↗
NASA NTRS2022

GRC MILab Software: Quick Start Guide

This document provides detailed installation and operating instructions for the GRC MILab Excel Add-In software developed at the NASA Glenn Research Center. The software described has been implemented to facilitate the process of importing into Microsoft Excel and analyzing materials test data from a wide range of materials tests. All resulting data is then ready for automated upload to the relevant table of the GRC Materials Intelligence (MI) database. This new software represents an update to the original MILab software developed by Granta Design Ltd.—a company specializing in materials software, data, and databases—for members of the Materials Data Management Consortium (MDMC), a collaboration between Granta, ASM International, NASA Glenn, and several other materials-oriented corporations and government agencies in the aerospace and defense industries. The updated software consists of the addition of two test type modules, the Generic and Generic Cyclic modules, with both representing a generalization of the original software. The Generic module supports the import and analysis of multiaxial data from any sequence of tensile, compression, relaxation, and/or creep test stages; and the Generic Cyclic module expands the functionality to include repeated sequences during cyclic testing. During processing, all imported data and analysis results are formatted by the software so as to be ready for immediate automated upload to the MI database, ensuring minimal overhead on the part of the user and access to persistent and reliable data for all relevant personnel.

Quick Start Guide↗
NASA NTRS2009

Modeling Guidelines for Code Generation in the Railway Signaling Context

Modeling guidelines constitute one of the fundamental cornerstones for Model Based Development. Their relevance is essential when dealing with code generation in the safety-critical domain. This article presents the experience of a railway signaling systems manufacturer on this issue. Introduction of Model-Based Development (MBD) and code generation in the industrial safety-critical sector created a crucial paradigm shift in the development process of dependable systems. While traditional software development focuses on the code, with MBD practices the focus shifts to model abstractions. The change has fundamental implications for safety-critical systems, which still need to guarantee a high degree of confidence also at code level. Usage of the Simulink/Stateflow platform for modeling, which is a de facto standard in control software development, does not ensure by itself production of high-quality dependable code. This issue has been addressed by companies through the definition of modeling rules imposing restrictions on the usage of design tools components, in order to enable production of qualified code. The MAAB Control Algorithm Modeling Guidelines (MathWorks Automotive Advisory Board)[3] is a well established set of publicly available rules for modeling with Simulink/Stateflow. This set of recommendations has been developed by a group of OEMs and suppliers of the automotive sector with the objective of enforcing and easing the usage of the MathWorks tools within the automotive industry. The guidelines have been published in 2001 and afterwords revisited in 2007 in order to integrate some additional rules developed by the Japanese division of MAAB [5]. The scope of the current edition of the guidelines ranges from model maintainability and readability to code generation issues. The rules are conceived as a reference baseline and therefore they need to be tailored to comply with the characteristics of each industrial context. Customization of these recommendations has been performed for the automotive control systems domain in order to enforce code generation [7]. The MAAB guidelines have been found profitable also in the aerospace/avionics sector [1] and they have been adopted by the MathWorks Aerospace Leadership Council (MALC). General Electric Transportation Systems (GETS) is a well known railway signaling systems manufacturer leading in Automatic Train Protection (ATP) systems technology. Inside an effort of adopting formal methods within its own development process, GETS decided to introduce system modeling by means of the MathWorks tools [2], and in 2008 chose to move to code generation. This article reports the experience performed by GETS in developing its own modeling standard through customizing the MAAB rules for the railway signaling domain and shows the result of this experience with a successful product development story.

Ferrari, Alessio↗
NASA NTRS1996

Development of software for the MSFC solar vector magnetograph

The Marshall Space Flight Center Solar Vector Magnetograph is a special purpose telescope used to measure the vector magnetic field in active areas on the surface of the sun. This instrument measures the linear and circular polarization intensities (the Stokes vectors Q, U and V) produced by the Zeeman effect on a specific spectral line due to the solar magnetic field from which the longitudinal and transverse components of the magnetic field may be determined. Beginning in 1990 as a Summer Faculty Fellow in project JOVE and continuing under NASA Grant NAG8-1042, the author has been developing computer software to perform these computations, first using a DEC MicroVAX system equipped with a high speed array processor, and more recently using a DEC AXP/OSF system. This summer's work is a continuation of this development.

Kineke, Jack↗
DOE OSTI2016

SWiFT Software Quality Assurance Plan.

This document describes the software development practice areas and processes which contribute to the ability of SWiFT software developers to provide quality software. These processes are designed to satisfy the requirements set forth by the Sandia Software Quality Assurance Program (SSQAP). APPROVALS SWiFT Software Quality Assurance Plan (SAND2016-0765) approved by: Department Manager SWiFT Site Lead Dave Minster (6121) Date Jonathan White (6121) Date SWiFT Controls Engineer Jonathan Berg (6121) Date CHANGE HISTORY Issue Date Originator(s) Description A 2016/01/27 Jon Berg (06121) Initial release of the SWiFT Software Quality Assurance Plan

97 MATHEMATICS AND COMPUTING↗
NASA NTRS1998

Testing and Troubleshooting Automatically Generated Source Code

Tools allowing engineers to model the real-time behavior of systems that control many types of NASA systems have become widespread. These tools automatically generate source code that is compiled, linked, then downloaded into computers controlling everything from wind tunnels to space flight systems. These tools save hundreds of hours of software development time and allow engineers with thorough application area knowledge but little software development experience to generate software to control the systems they use daily. These systems are verified and validated by simulating the real-time models, and by other techniques that focus on the model or the hardware. The automatically generated source code is typically not subjected to rigorous testing using conventional software testing techniques. Given the criticality and safety issues surrounding these systems, the application of conventional and new software testing and troubleshooting techniques to the automatically generated will improve the reliability of the resulting systems.

Henry, Joel↗
NASA NTRS1981

Identification and evaluation of software measures

A large scale, systematic procedure for identifying and evaluating measures that meaningfully characterize one or more elements of software development is described. The background of this research, the nature of the data involved, and the steps of the analytic procedure are discussed. An example of the application of this procedure to data from real software development projects is presented. As the term is used here, a measure is a count or numerical rating of the occurrence of some property. Examples of measures include lines of code, number of computer runs, person hours expended, and degree of use of top down design methodology. Measures appeal to the researcher and the manager as a potential means of defining, explaining, and predicting software development qualities, especially productivity and reliability.

Card, D. N.↗
NASA NTRS1996

Planetary Atmosphere Dynamics and Radiative Transfer

This research program has dealt with two projects in the field of planetary atmosphere dynamics and radiative energy transfer, one theoretical and one experimental. The first project, in radiative energy transfer, incorporated the capability to isolate and quantify the contribution of individual atmospheric components to the Venus radiative balance and thermal structure to greatly improve the current understanding of the radiative processes occurring within the Venus atmosphere. This is possible by varying the mixing ratios of each gas species, and the location, number density and aerosol size distributions of the clouds. This project was a continuation of the work initiated under a 1992 University Consortium Agreement. Under the just completed grant, work has continued on the use of a convolution-based algorithm that provided the capability to calculate the k coefficients of a gas mixture at different temperatures, pressures and spectral intervals from the separate k-distributions of the individual gas species. The second primary goal of this research dealt with the Doppler wind retrieval for the Successful Galileo Jupiter probe mission in December, 1995. In anticipation of the arrival of Galileo at Jupiter, software development continued to read the radioscience and probe/orbiter trajectory data provided by the Galileo project and required for Jupiter zonal wind measurements. Sample experiment radioscience data records and probe/orbiter trajectory data files provided by the Galileo Radioscience and Navigation teams at the Jet Propulsion Laboratory, respectively, were used for the first phase of the software development. The software to read the necessary data records was completed in 1995. The procedure by which the wind retrieval takes place begins with initial consistency checks of the raw data, preliminary data reductions, wind recoveries, iterative reconstruction of the probe descent profile, and refined wind recoveries. At each stage of the wind recovery consistency is checked and maintained between the orbiter navigational data, the radioscience data, and the probe descent profile derived by the Atmospheric Instrument Team. Preliminary results show that the zonal winds at Jupiter increase with depth to approximately 150 m/s.

Atkinson, David H.↗
NASA NTRS2014

Formal Methods Case Studies for DO-333

RTCA DO-333, Formal Methods Supplement to DO-178C and DO-278A provides guidance for software developers wishing to use formal methods in the certification of airborne systems and air traffic management systems. The supplement identifies the modifications and additions to DO-178C and DO-278A objectives, activities, and software life cycle data that should be addressed when formal methods are used as part of the software development process. This report presents three case studies describing the use of different classes of formal methods to satisfy certification objectives for a common avionics example - a dual-channel Flight Guidance System. The three case studies illustrate the use of theorem proving, model checking, and abstract interpretation. The material presented is not intended to represent a complete certification effort. Rather, the purpose is to illustrate how formal methods can be used in a realistic avionics software development project, with a focus on the evidence produced that could be used to satisfy the verification objectives found in Section 6 of DO-178C.

Cofer, Darren↗
NASA NTRS2005

Software Engineering Research/Developer Collaborations in 2004 (C104)

In 2004, six collaborations between software engineering technology providers and NASA software development personnel deployed a total of five software engineering technologies (for references, see Section 7.2) on the NASA projects. The main purposes were to benefit the projects, infuse the technologies if beneficial into NASA, and give feedback to the technology providers to improve the technologies. Each collaboration project produced a final report (for references, see Section 7.1). Section 2 of this report summarizes each project, drawing from the final reports and communications with the software developers and technology providers. Section 3 indicates paths to further infusion of the technologies into NASA practice. Section 4 summarizes some technology transfer lessons learned. Section 6 lists the acronyms used in this report.

Pressburger, Tom↗
NASA NTRS1992

A proposed research program in information processing

The goal of the Formalized Software Development (FSD) project was to demonstrate improvements productivity of software development and maintenance through the use of a new software lifecycle paradigm. The paradigm calls for the mechanical, but human-guided, derivation of software implementations from formal specifications of the desired software behavior. It relies on altering a system's specification and rederiving its implementation as the standard technology for software maintenance. A system definition for this paradigm is composed of a behavioral specification together with a body of annotations that control the derivation of executable code from the specification. Annotations generally achieve the selection of certain data representations and/or algorithms that are consistent with, but not mandated by, the behavioral specification. In doing this, they may yield systems which exhibit only certain behaviors among multiple alternatives permitted by the behavioral specification. The FSD project proposed to construct a testbed in which to explore the realization of this new paradigm. The testbed was to provide operational support environment for software design, implementation, and maintenance. The testbed was proposed to provide highly automated support for individual programmers ('programming in the small'), but not to address the additional needs of programming teams ('programming in the large'). The testbed proposed to focus on supporting rapid construction and evolution of useful prototypes of software systems, as opposed to focusing on the problems of achieving production quality performance of systems.

Schorr, Herbert↗
NASA NTRS1993

Development Of Software To Recognize Parts Of Plants

Report describes first phase in development of digital image-processing subsystem recognizing parts of plants. Subsystem part of robotic system tending and harvesting plants in automated plant-growth chamber. Initial focus on image-processing software that distinguishes among seed heads, stems, and leaves of wheat plants and further distinguishes between these parts and background. Software adaptable to other types of plants.

Despain, Ronald R.↗
NASA NTRS1998

Framework for Small-Scale Experiments in Software Engineering: Guidance and Control Software Project: Software Engineering Case Study

Software is becoming increasingly significant in today's critical avionics systems. To achieve safe, reliable software, government regulatory agencies such as the Federal Aviation Administration (FAA) and the Department of Defense mandate the use of certain software development methods. However, little scientific evidence exists to show a correlation between software development methods and product quality. Given this lack of evidence, a series of experiments has been conducted to understand why and how software fails. The Guidance and Control Software (GCS) project is the latest in this series. The GCS project is a case study of the Requirements and Technical Concepts for Aviation RTCA/DO-178B guidelines, Software Considerations in Airborne Systems and Equipment Certification. All civil transport airframe and equipment vendors are expected to comply with these guidelines in building systems to be certified by the FAA for use in commercial aircraft. For the case study, two implementations of a guidance and control application were developed to comply with the DO-178B guidelines for Level A (critical) software. The development included the requirements, design, coding, verification, configuration management, and quality assurance processes. This paper discusses the details of the GCS project and presents the results of the case study.

Hayhurst, Kelly J.↗
NASA NTRS1992

Data collection procedures for the Software Engineering Laboratory (SEL) database

This document is a guidebook to collecting software engineering data on software development and maintenance efforts, as practiced in the Software Engineering Laboratory (SEL). It supersedes the document entitled Data Collection Procedures for the Rehosted SEL Database, number SEL-87-008 in the SEL series, which was published in October 1987. It presents procedures to be followed on software development and maintenance projects in the Flight Dynamics Division (FDD) of Goddard Space Flight Center (GSFC) for collecting data in support of SEL software engineering research activities. These procedures include detailed instructions for the completion and submission of SEL data collection forms.

Heller, Gerard↗