SEARCH · Engineering Papers

Results for “Software Requirements”

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 1,117 records · Page 62

All sources NASA NTRS DOE OSTI

NASA NTRS1992

Rapid development of the X-31 simulation to support flight-testing

The X-31 Enhanced Fighter Maneuverability Program has been recognized to form the International Test Organization, with the NASA Dryden Flight Research Facility (NASA-Dryden) as the responsible test organization. The two X-31 research aircraft and engineering support personnel were colocated at NASA-Dryden, with flight test operations beginning in Apr. 1992. Therefore, rapid development of a hardware-in-the-loop simulation was needed to support the flight test operations at NASA-Dryden, and to perform verification and validation of flight control software. The X-31 simulation system requirements, distributed simulation system architecture, simulation components math models to the visual system, and the advanced capabilities the X-31 simulation provides. In addition, unique software tools and the methods used to rapidly develop this simulation system will be highlighted.

Mackall, Dale↗

NASA NTRS2011

Software-Defined Radio for Space-to-Space Communications

A paper describes the Space- to-Space Communications System (SSCS) Software- Defined Radio (SDR) research project to determine the most appropriate method for creating flexible and reconfigurable radios to implement wireless communications channels for space vehicles so that fewer radios are required, and commonality in hardware and software architecture can be leveraged for future missions. The ability to reconfigure the SDR through software enables one radio platform to be reconfigured to interoperate with many different waveforms. This means a reduction in the number of physical radio platforms necessary to support a space mission s communication requirements, thus decreasing the total size, weight, and power needed for a mission.

Fisher, Ken↗

NASA NTRS2004

Software for Analyzing Laminar-to-Turbulent Flow Transitions

Software assurance is the planned and systematic set of activities that ensures that software processes and products conform to requirements, standards, and procedures. Examples of such activities are the following: code inspections, unit tests, design reviews, performance analyses, construction of traceability matrices, etc. In practice, software development projects have only limited resources (e.g., schedule, budget, and availability of personnel) to cover the entire development effort, of which assurance is but a part. Projects must therefore select judiciously from among the possible assurance activities. At its heart, this can be viewed as an optimization problem; namely, to determine the allocation of limited resources (time, money, and personnel) to minimize risk or, alternatively, to minimize the resources needed to reduce risk to an acceptable level. The end result of the work reported here is a means to optimize quality-assurance processes used in developing software. This is achieved by combining two prior programs in an innovative manner

Chang, Chau-Lyan↗

NASA NTRS2004

Software for Optimizing Quality Assurance of Other Software

Feather, Martin↗

NASA NTRS2022

Flight Software Dictionary Development for the Mars2020 Rover

The Mars2020 project, developed and operated by the Jet Propulsion Laboratory (JPL), successfully landed the Perseverance rover and its flying companion Ingenuity on the surface of Mars on February 18th 2021. Perseverance combines heritage and cutting-edge flight software and hardware to accomplish crucial mission requirements related to Martian surface sampling. The design, development, and operation of NASA’s large strategic science missions require the ability to communicate spacecraft capabilities to hundreds of engineers across multiple disciplines. The interaction between flight and ground software development, Verification and Validation (V&V), Assembly, Test, and Launch Operations (ATLO), and management each demand quick understanding of unique slices of information for each discipline. This information includes the current capabilities of the flight system as well as future capabilities and their status as they are developed and tested. Despite the fundamental and critical nature of this information, the flight software dictionaries used to track it are a stumbling block for many projects. These dictionaries provide the cornerstone for the interpretation of data sent from the spacecraft, allowing for quick comprehension by engineers on the ground. During both spacecraft development and operations, flight software dictionary management includes significant challenges due to the large number of interfacing systems and the subtle yet distinct needs of each.The engineering of flight software dictionaries for Mars2020 had numerous challenges, most-notably: parallel dictionary development to support simultaneous separate flight software build campaigns for each mission phase (cruise and surface), managing requests for operations-enabling information without perturbing the heritage interface with the rover, and the introduction of new tools by the dictionary stakeholders that forced the dictionary team to innovate and redesign the heritage tool chain. These challenges generated guiding principles for the dictionary development effort: emphasize coding best practices and unit testing in the dictionary code development tool chain, use institutionally provided COTS (commercial-off-the-shelf) tools whenever possible, and maintain the heritage flight-ground interface all while advancing operations-enabling information via a loosely coupled interface.Throughout development and operations, the Mars2020 dictionary toolchain included IBM DOORS Next Generation, GitHub, Microsoft Excel, Docker, Jenkins, and a significant custom-built Python codebase. Significant interfaces included JPL’s command and control software, heritage flight software team tools and processes, and the many cloud-based ground tools developed for the mission.This paper will discuss the requirements for the Mars2020 dictionary development, the development team’s response to those requirements, lessons learned throughout the process, steps taken towards automated deliveries and continuous integration of stakeholder inputs, potential toolchain improvements for Mars2020, and key takeaways that could be applied to future missions.

Pyrzak, Guy↗

NASA NTRS2021

Casual Rerouting of AERONET Sun/Sky Photometers: Toward a New Network of Ground Measurements Dedicated to the Monitoring of Surface Properties?

This paper presents an innovative method for observing vegetation health at a very high spatial resolution (~5 × 5 cm) and low cost by upgrading an existing Aerosol RObotic NETwork (AERONET) ground station dedicated to the observation of aerosols in the atmosphere. This study evaluates the capability of a sun/sky photometer to perform additional surface reflectance observations. The ground station of Toulouse, France, which belongs to the AERONET sun/sky photometer network, is used for this feasibility study. The experiment was conducted for a 5-year period (between 2016 and 2020). The sun/sky photometer was mounted on a metallic structure at a height of 2.5 m, and the acquisition software was adapted to add a periodical (every hour) ground-observation scenario with the sun/sky photometer observing the surface instead of being inactive. Evaluation is performed by using a classical metric characterizing the vegetation health: the normalized difference vegetation index (NDVI), using as reference the satellite NDVI derived from a Sentinel-2 (S2) sensor at 10 × 10 m resolution. Comparison for the 5-year period showed good agreement between the S2 and sun/sky photometer NDVIs (i.e., bias = 0.004, RMSD = 0.082, and R = 0.882 for a mean value of S2A NDVI around 0.6). Discrepancies could have been due to spatial-representativeness issues (of the ground measurement compared to S2), the differences between spectral bands, and the quality of the atmospheric correction applied on S2 data (accuracy of the sun/sky photometer instrument was better than 0.1%). However, the accuracy of the atmospheric correction applied on S2 data in this station appeared to be of good quality, and no dependence on the presence of aerosols was observed. This first analysis of the potential of the CIMEL CE318 sun/sky photometer to monitor the surface is encouraging. Further analyses need to be carried out to estimate the potential in different AERONET stations. The occasional rerouting of AERONET stations could lead to a complementary network of surface reflectance observations. This would require an update of the software, and eventual adaptations of the measurement platforms to the station environments. The additional cost, based on the existing AERONET network, would be quite limited. These new surface measurements would be interesting for measurements of vegetation health (monitoring of NDVI, and also of other vegetation indices such as the leaf area and chlorophyll indices), for validation and calibration exercise purposes, and possibly to refine various scientific algorithms (i.e., algorithms dedicated to cloud detection or the AERONET aerosol retrieval algorithm itself). CIMEL is ready to include the ground scenario used in this study in all new sun/sky photometers.

Dominique Carrer↗

NASA NTRS2018

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.↗

DOE OSTI2025

Protocol to detect dilution cycles in chemostat experiments and estimate growth rate slopes with linear modeling with R software chemostat_regression

Chemostat growth chambers measure optical density over time and require manual calculation of growth rates. Here, we present chemostat_regression, R software that enables users to automatically identify chemostat cycles and estimate growth rate using a linear regression approach. We describe steps for creating requisite software environment(s), formatting input data, executing the software via command line/RStudio/R-Shiny, interpreting results, assessing the validity of results, and modifying input parameters.

59 BASIC BIOLOGICAL SCIENCES↗

NASA NTRS1991

Lunar rovers and local positioning system

Telerobotic rovers equipped with adequate actuators and sensors are clearly necessary for extraterrestrial construction. They will be employed as substitutes for humans, to perform jobs like surveying, sensing, signaling, manipulating, and the handling of small materials. Important design criteria for these rovers include versatility and robustness. They must be easily programmed and reprogrammed to perform a wide variety of different functions, and they must be robust so that construction work will not be jeopardized by parts failures. The key qualities and functions necessary for these rovers to achieve the required versatility and robustness are modularity, redundancy, and coordination. Three robotic rovers are being built by CSC as a test bed to implement the concepts of modularity and coordination. The specific goal of the design and construction of these robots is to demonstrate the software modularity and multirobot control algorithms required for the physical manipulation of constructible elements. Each rover consists of a transporter platform, bus manager, simple manipulator, and positioning receivers. These robots will be controlled from a central control console via a radio-frequency local area network (LAN). To date, one prototype transporter platform frame was built with batteries, motors, a prototype single-motor controller, and two prototype internal LAN boards. Software modules were developed in C language for monitor functions, i/o, and parallel port usage in each computer board. Also completed are the fabrication of half of the required number of computer boards, the procurement of 19.2 Kbaud RF modems for inter-robot communications, and the simulation of processing requirements for positioning receivers. In addition to the robotic platform, the fabrication of a local positioning system based on infrared signals is nearly completed. This positioning system will make the rovers into a moving reference system capable of performing site surveys. In addition, a four degree mechanical manipulator especially suited for coordinated teleoperation was conceptually designed and is currently being analyzed. This manipulator will be integrated into the rovers as their end effector. Twenty internal LAN cards fabricated by a commercial firm are being used, a prototype manipulator and a range finder for a positioning system were built, a prototype two-motor controller was designed, and one of the robots is performing its first telerobotic motion. In addition, the robots' internal LAN's were coordinated and tested, hardware design upgrades based on fabrication and fit experience were completed, and the positioning system is running. The rover system is able to perform simple tasks such as sensing and signaling; coordination systems which allow construction tasks to begin were established, and soon coordinated teams of robots in the laboratory will be able to manipulate common objects.

Avery, James↗

NASA NTRS1988

Wall adjustment strategy software for use with the NASA Langley 0.3-meter transonic cryogenic tunnel adaptive wall test section

The Wall Adjustment Strategy (WAS) software provides successful on-line control of the 2-D flexible walled test section of the Langley 0.3-m Transonic Cryogenic Tunnel. This software package allows the level of operator intervention to be regulated as necessary for research and production type 2-D testing using and Adaptive Wall Test Section (AWTS). The software is designed to accept modification for future requirements, such as 3-D testing, with a minimum of complexity. The WAS software described is an attempt to provide a user friendly package which could be used to control any flexible walled AWTS. Control system constraints influence the details of data transfer, not the data type. Then this entire software package could be used in different control systems, if suitable interface software is available. A complete overview of the software highlights the data flow paths, the modular architecture of the software and the various operating and analysis modes available. A detailed description of the software modules includes listings of the code. A user's manual is provided to explain task generation, operating environment, user options and what to expect at execution.

Wolf, Stephen W. D.↗

NASA NTRS1992

Trajectory design and navigation analysis for Cargo Transfer Vehicle proximity operations

The paper documents an investigation of alternative (or off-nominal) final approach trajectories and terminal guidance algorithms for Cargo Transfer Vehicle (CTV) automated rendezvous and proximity operation in the vicinity of Space Station Freedom (SSF). Ten candidate trajectory designs, representing a survey of all approaches that reasonably satisfy the mission constraints, are compared qualitatively and quantitatively. It is shown that several fundamentally different types of approach strategies are feasible in the CTV application and enjoy more favorable passive collision avoidance and plume impingement properties than the nominal. They are, however, generally more costly in propellant. The extent to which an alternative approach is more costly is determined largely by the abort (or specifically the 'hold' or 'wave-off') requirements. These approach techniques are verified in a software simulation using a parametrically defined candidate navigation system, and proximity sensor accuracy requirements are derived.

Marsh, S. M.↗

NASA NTRS1992

Advanced Communications Technology Satellite high burst rate link evaluation terminal experiment control and monitor software maintenance manual, version 1.0

The Experiment Control and Monitor (EC&M) software was developed at NASA Lewis Research Center to support the Advanced Communications Technology Satellite (ACTS) High Burst Rate Link Evaluation Terminal (HBR-LET). The HBR-LET is an experimenter's terminal to communicate with the ACTS for various investigations by government agencies, universities, and industry. The EC&M software is one segment of the Control and Performance Monitoring (C&PM) software system of the HBR-LET. The EC&M software allows users to initialize, control, and monitor the instrumentation within the HBR-LET using a predefined sequence of commands. Besides instrument control, the C&PM software system is also responsible for computer communication between the HBR-LET and the ACTS NASA Ground Station and for uplink power control of the HBR-LET to demonstrate power augmentation during rain fade events. The EC&M Software User's Guide, Version 1.0 (NASA-CR-189160) outlines the commands required to install and operate the EC&M software. Input and output file descriptions, operator commands, and error recovery procedures are discussed in the document. The EC&M Software Maintenance Manual, Version 1.0 (NASA-CR-189161) is a programmer's guide that describes current implementation of the EC&M software from a technical perspective. An overview of the EC&M software, computer algorithms, format representation, and computer hardware configuration are included in the manual.

Reinhart, Richard C.↗

NASA NTRS1992

Modeling software systems by domains

The Software Architectures Engineering (SAE) Project at the Software Engineering Institute (SEI) has developed engineering modeling techniques that both reduce the complexity of software for domain-specific computer systems and result in systems that are easier to build and maintain. These techniques allow maximum freedom for system developers to apply their domain expertise to software. We have applied these techniques to several types of applications, including training simulators operating in real time, engineering simulators operating in non-real time, and real-time embedded computer systems. Our modeling techniques result in software that mirrors both the complexity of the application and the domain knowledge requirements. We submit that the proper measure of software complexity reflects neither the number of software component units nor the code count, but the locus of and amount of domain knowledge. As a result of using these techniques, domain knowledge is isolated by fields of engineering expertise and removed from the concern of the software engineer. In this paper, we will describe kinds of domain expertise, describe engineering by domains, and provide relevant examples of software developed for simulator applications using the techniques.

Dippolito, Richard↗

NASA NTRS1992

Advanced communications technology satellite high burst rate link evaluation terminal experiment control and monitor software user's guide, version 1.0

Reinhart, Richard C.↗

NASA NTRS1999

Flight Software Design Choices Based on Criticality

This slide presentation reviews the rationale behind flight software design as a function of criticality. The requirements of human rated systems implies a high criticality for the flight support software. Human life is dependent on correct operation of the software. Flexibility should be permitted when the consequences of software failure are not life threatening. This is also relevant for selecting Commercial Off the Shelf (COTS) software.

Lee, Earl↗

NASA NTRS2003

Promising More Information

When NASA needed a real-time, online database system capable of tracking documentation changes in its propulsion test facilities, engineers at Stennis Space Center joined with ECT International, of Brookfield, Wisconsin, to create a solution. Through NASA's Dual-Use Program, ECT developed Exdata, a software program that works within the company's existing Promise software. Exdata not only satisfied NASA s requirements, but also expanded ECT s commercial product line. Promise, ECT s primary product, is an intelligent software program with specialized functions for designing and documenting electrical control systems. An addon to AutoCAD software, Promis e generates control system schematics, panel layouts, bills of material, wire lists, and terminal plans. The drawing functions include symbol libraries, macros, and automatic line breaking. Primary Promise customers include manufacturing companies, utilities, and other organizations with complex processes to control.

Source record↗

NASA NTRS1984

Software modifications to the Demonstration Advanced Avionics Systems (DAAS)

Critical information required for the design of integrated avionics suitable for generation aviation is applied towards software modifications for the Demonstration Advanced Avionics System (DAAS). The program emphasizes the use of data busing, distributed microprocessors, shared electronic displays and data entry devices, and improved functional capability. A demonstration advanced avionics system (DAAS) is designed, built, and flight tested in a Cessna 402, twin engine, general aviation aircraft. Software modifications are made to DAAS at Ames concurrent with the flight test program. The changes are the result of the experience obtained with the system at Ames, and the comments of the pilots who evaluated the system.

Nedell, B. F.↗

NASA NTRS1973

Design of the software development and verification system (SWDVS) for shuttle NASA study task 35

An overview of the Software Development and Verification System (SWDVS) for the space shuttle is presented. The design considerations, goals, assumptions, and major features of the design are examined. A scenario that shows three persons involved in flight software development using the SWDVS in response to a program change request is developed. The SWDVS is described from the standpoint of different groups of people with different responsibilities in the shuttle program to show the functional requirements that influenced the SWDVS design. The software elements of the SWDVS that satisfy the requirements of the different groups are identified.

Drane, L. W.↗