Engineering Papers⌕ Search

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.

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

At least 721 records · Page 40

Enabling a Voice Management System for Space Applications, Design and Software Development

Sustainable missions, beyond low Earth orbit, will require autonomous capabilities in order to achieve NASA’s Artemis program objectives. Correspondingly, the crew must have a means to efficiently interact with these autonomous systems; this can be facilitated via voice and speech communications. Voice-based controls enable the user to access autonomous systems hands-free/eyes-free, allowing the user to better focus on critical tasks. The goal of this project was to explore the knowledge and technology needed to successfully design effective voice interfaces for autonomous systems. The main objective was to understand how a crew member, through voice interaction, could most efficiently and intuitively communicate with a notional autonomous vehicle system manager. This project leveraged prior research conducted by the University of Michigan’s Bioastronautics and Life Support System (BLiSS) team as part of a NASA Moon to Mars eXploration Systems and Habitation (M2M X-Hab) 2020 Academic Innovation Challenge. The X-Hab 2020 work from the BliSS Team resulted in an intuitive graphical user interface/user experience that was built on an Internet of Things (IOT) platform. The Voice User Interface (VUI) design for the M2M X-Hab 2021 project leveraged this technology and incorporated a voice-based assistant and NASA’s Platform for Autonomous Systems (NPAS) software. This required technologies to convert voice to text, conduct semantic interpretations, and convert responses from the autonomous system to text and to speech; additionally, the background noise environment of spacecraft was assessed, and a relatable personality for the autonomous system to facilitate human-like conversations was created. This work’s success was largely due to the diverse team that included expertise in Space Systems Engineering, Human Computer Interaction, Aerospace Engineering, Computer Science, Biomedical Engineering, and Applied Physics. The differing perspectives fostered elaborate discussions, resulting in the conception of three main interactions: (1) User-System, (2) NPAS-System, and (3) Environment-System. The system developed, i.e. the VUI, had to be unique, efficient, and intuitive; thus, the team crafted a personality for the system to enable human-like conversation. User surveys sent to students and young professionals were used to help determine these personality traits by capturing perspectives and expectations of the “Artemis Generation Astronauts”. To further simulate human-like conversations, the system had to be able to quickly interpret user speech and be able to integrate with NASA’s NPAS system for quick and reliable information transfer. Results of this research include (1) a working prototype user interface, that is compatible with NASA’s NPAS system; (2) software that demonstrates the ability to interpret user requests and respond appropriately; (3) the capability to implement fully expanded conversations between user and system using intuitive communication in four request categories; and (4) software and hardware recommendations that optimize the system’s ability to operate, i.e. be heard, in a noisy environment. The technologies chosen for this project’s demonstrations included the following: Raspberry Pi, RASA, Mozilla Deep Speech, Coqui, RTX Voice and Adobe XD. This work has laid the foundation for the development of VUI’s used for autonomy, and is intended to provide guidance for future VUI development.

Tara Vega↗

IGDS/TRAP Interface Program (ITIP). Software User Manual (SUM)

This specification establishes the requirements, concepts, and preliminary design for a set of software known as the IGDS/TRAP Interface Program (ITIP). This software provides the capability to develop at an Interactive Graphics Design System (IGDS) design station process flow diagrams for use by the NASA Coal Gasification Task Team. In addition, ITIP will use the Data Management and Retrieval System (DMRS) to maintain a data base from which a properly formatted input file to the Time-Line and Resources Analysis Program (TRAP) can be extracted. This set of software will reside on the PDP-11/70 and will become the primary interface between the Coal Gasification Task Team and IGDS, DMRS, and TRAP. The user manual for the computer program is presented.

Jefferys, S.↗

NASA Data Acquisition System Software Development for Rocket Propulsion Test Facilities

Current NASA propulsion test facilities include Stennis Space Center in Mississippi, Marshall Space Flight Center in Alabama, Plum Brook Station in Ohio, and White Sands Test Facility in New Mexico. Within and across these centers, a diverse set of data acquisition systems exist with different hardware and software platforms. The NASA Data Acquisition System (NDAS) is a software suite designed to operate and control many critical aspects of rocket engine testing. The software suite combines real-time data visualization, data recording to a variety formats, short-term and long-term acquisition system calibration capabilities, test stand configuration control, and a variety of data post-processing capabilities. Additionally, data stream conversion functions exist to translate test facility data streams to and from downstream systems, including engine customer systems. The primary design goals for NDAS are flexibility, extensibility, and modularity. Providing a common user interface for a variety of hardware platforms helps drive consistency and error reduction during testing. In addition, with an understanding that test facilities have different requirements and setups, the software is designed to be modular. One engine program may require real-time displays and data recording; others may require more complex data stream conversion, measurement filtering, or test stand configuration management. The NDAS suite allows test facilities to choose which components to use based on their specific needs. The NDAS code is primarily written in LabVIEW, a graphical, data-flow driven language. Although LabVIEW is a general-purpose programming language; large-scale software development in the language is relatively rare compared to more commonly used languages. The NDAS software suite also makes extensive use of a new, advanced development framework called the Actor Framework. The Actor Framework provides a level of code reuse and extensibility that has previously been difficult to achieve using LabVIEW. The

Herbert, Phillip W., Sr.↗

Chandra Space Flight Software: Using Software to Autonomously Operation the Largest and Most Sensitive X-Ray Telescope in the World

Chandra is the world's largest and most sensitive X-ray telescope. The Chandra X-ray Observatory is the third in NASA's family of "Great Observatories." The Chandra X-ray Observatory, launched by Space Shuttle Columbia on July 23, 1999, is NASA's newest Great Observatory. The Chandra space flight software is the operational software, which controls and directs the Chandra X-ray Observatory. The Chandra flight software has executed faultlessly for over 13,000 hours on-orbit. The Chandra flight software directly controls the Pointing, Aspect Determination, Electrical Power Subsystem, Propulsion system, and the Command, Communications, and Data Management subsystems. The software controls the spacecraft operations during all phases of the mission. The software also performs thermal control of the telescope to maintain pointing accuracy and monitors radiation levels throughout the orbit so that the Science Instruments can be safed if radiation thresholds are exceeded. The efficient operation of Chandra flight software has enabled the gathering of crucial science data. The Chandra flight software fault protection is the key to early detection and prevention of science instrument or spacecraft damage in an operating platform/environment, which is completely unforgiving. Permanently open Sun Shade Door and ACIS focal plane radiator sensitivity exposes science instruments and mirrors to damage for pointing anomalies causing an attitude excursion. The Chandra flight software must prevent these attitude excursions from occurring for ANY failure. Another example is that the power system has an unregulated bus, which imposes severe operating requirements on Chandra flight software to control array pointing and battery connection/disconnect using a unique algorithmic and logic approach. The Chandra flight software has enabled a truly autonomous vehicle with greater than 99% of all mission data collected as planned. Less than 15% of spacecraft operations are conducted in view (1 hour out of 8) leading to very extended periods without ground contact. The Chandra flight software implements the flexible mission plan during this out of view period, manages the solid state recorder capacity, controls all pointing and maneuvers, provides fault detection for all satellite subsystems, and initiates communications with the ground at the appropriate time. This paper will describe the software architecture features, key design elements and software testing techniques that have facilitated Chandra's success.

Crumbley, Tim↗

Discovery and repair of software anomalies

The average time required to discover and repair anomalies which appear randomly in the end-to-end tests performed after program completion is evaluated. A model which explains anomaly discovery and repair phenomena when applied to variations in work load and multiple-stage testing is presented. The theory shows that estimates of anomaly levels and team capability can be predicted after a significant fraction of the anomalies have been found, and indicates procedures for applying these figures to schedule estimation and work-load assignment. Of particular interest is the demonstration that end-to-end testing of programs in other than the operational environment is not generally cost effective.

Tausworthe, R. C.↗

Software Engineering Improvement Activities/Plan

bd Systems personnel accomplished the technical responsibilities for this reporting period, as planned. A close working relationship was maintained with personnel of the MSFC Avionics Department Software Group (ED14). Work accomplishments included development, evaluation, and enhancement of a software cost model, performing literature search and evaluation of software tools available for code analysis and requirements analysis, and participating in other relevant software engineering activities. Monthly reports were submitted. This support was provided to the Flight Software Group/ED 1 4 in accomplishing the software engineering improvement engineering activities of the Marshall Space Flight Center (MSFC) Software Engineering Improvement Plan.

Source record↗

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↗

Distributed Engine Control Empirical/Analytical Verification Tools

NASA's vision for an intelligent engine will be realized with the development of a truly distributed control system featuring highly reliable, modular, and dependable components capable of both surviving the harsh engine operating environment and decentralized functionality. A set of control system verification tools was developed and applied to a C-MAPSS40K engine model, and metrics were established to assess the stability and performance of these control systems on the same platform. A software tool was developed that allows designers to assemble easily a distributed control system in software and immediately assess the overall impacts of the system on the target (simulated) platform, allowing control system designers to converge rapidly on acceptable architectures with consideration to all required hardware elements. The software developed in this program will be installed on a distributed hardware-in-the-loop (DHIL) simulation tool to assist NASA and the Distributed Engine Control Working Group (DECWG) in integrating DCS (distributed engine control systems) components onto existing and next-generation engines.The distributed engine control simulator blockset for MATLAB/Simulink and hardware simulator provides the capability to simulate virtual subcomponents, as well as swap actual subcomponents for hardware-in-the-loop (HIL) analysis. Subcomponents can be the communication network, smart sensor or actuator nodes, or a centralized control system. The distributed engine control blockset for MATLAB/Simulink is a software development tool. The software includes an engine simulation, a communication network simulation, control algorithms, and analysis algorithms set up in a modular environment for rapid simulation of different network architectures; the hardware consists of an embedded device running parts of the CMAPSS engine simulator and controlled through Simulink. The distributed engine control simulation, evaluation, and analysis technology provides unique capabilities to study the effects of a given change to the control system in the context of the distributed paradigm. The simulation tool can support treatment of all components within the control system, both virtual and real; these include communication data network, smart sensor and actuator nodes, centralized control system (FADEC full authority digital engine control), and the aircraft engine itself. The DECsim tool can allow simulation-based prototyping of control laws, control architectures, and decentralization strategies before hardware is integrated into the system. With the configuration specified, the simulator allows a variety of key factors to be systematically assessed. Such factors include control system performance, reliability, weight, and bandwidth utilization.

DeCastro, Jonathan↗

QFD Application to a Software - Intensive System Development Project

This paper describes the use of Quality Function Deployment (QFD), adapted to requirements engineering for a software-intensive system development project, and sysnthesizes the lessons learned from the application of QFD to the Network Control System (NCS) pre-project of the Deep Space Network.

QFD Quality Function Deployment NCS Network Contro↗

Next Gen One Portal Usability Evaluation

Each exercise device on the International Space Station (ISS) has a unique, customized software system interface with unique layouts / hierarchy, and operational principles that require significant crew training. Furthermore, the software programs are not adaptable and provide no real-time feedback or motivation to enhance the exercise experience and/or prevent injuries. Additionally, the graphical user interfaces (GUI) of these systems present information through multiple layers resulting in difficulty navigating to the desired screens and functions. These limitations of current exercise device GUI's lead to increased crew time spent on initiating, loading, performing exercises, logging data and exiting the system. To address these limitations a Next Generation One Portal (NextGen One Portal) Crew Countermeasure System (CMS) was developed, which utilizes the latest industry guidelines in GUI designs to provide an intuitive ease of use approach (i.e., 80% of the functionality gained within 5-10 minutes of initial use without/limited formal training required). This is accomplished by providing a consistent interface using common software to reduce crew training, increase efficiency & user satisfaction while also reducing development & maintenance costs. Results from the usability evaluations showed the NextGen One Portal UI having greater efficiency, learnability, memorability, usability and overall user experience than the current Advanced Resistive Exercise Device (ARED) UI used by astronauts on ISS. Specifically, the design of the One-Portal UI as an app interface similar to those found on the Apple and Google's App Store, assisted many of the participants in grasping the concepts of the interface with minimum training. Although the NextGen One-Portal UI was shown to be an overall better interface, observations by the test facilitators noted specific exercise tasks appeared to have a significant impact on the NextGen One-Portal UI efficiency. Future updates to the NextGen One Portal UI will address these inefficiencies.

Cross, E. V., III↗

In the soft-to-hard technical spectrum: Where is software engineering?

In the computer journals and tabloids, there have been a plethora of articles written about the software engineering field. But while advocates of the need for an engineering approach to software development, it is impressive how many authors have treated the subject of software engineering without adequately addressing the fundamentals of what engineering as a discipline consists of. A discussion is presented of the various related facets of this issue in a logical framework to advance the thesis that the software development process is necessarily an engineering process. The purpose is to examine more of the details of the issue of whether or not the design and development of software for digital computer processing systems should be both viewed and treated as a legitimate field of professional engineering. Also, the type of academic and professional level education programs that would be required to support a software engineering discipline is examined.

Leibfried, Theodore F.↗

Upgrades to Common Data Acquisition System Software Development for NASA's Rocket Propulsion Test Facilities and Software Reuse

Approximately five years ago, the National Aeronautics and Space Administration (NASA) Stennis Space Center (SSC) resumed operation of its large rocket engine test facilities after thirty years of contractor control. During this period, contactors used their own proprietary Data Acquisition System (DAS) to record and process rocket propulsion test data. The transition from a contractor managed facility to a NASA managed facility posed a difficult challenge. In order to support the commercial space launch initiative, SSC needed to develop a software replacement for the contractor proprietary DAS. This replacement software would enable SSC to operate propulsion test facilities more cost effectively and to be more readily able to adapt software for reuse, while at the same time provide internal and external customers with reliable population test data. Therefore, SSC developed in-house, a non-proprietary software suite of applications to replace the previously used proprietary DAS. The requirements for the DAS suite included recording and processing propulsion test data. This capability eliminates the necessity for customers to provide a DAS or rely on a competitor's DAS. An additional benefit of owning the software suite included enabling the ability to add additional features and functionality at a lower cost. The Rocket Propulsion Test (RPT) Program Office reviewed consideration for funding this project with the caveat that development of the software included availability for use with minimal modifications to all SSC test facilities and RPT centers: Marshall Space Flight Center (MSFC), White Sands Test Facility (WSTF), and Glenn Research Center (GRC) Plum Brook Station. Based upon this guideline, SSC created the NASA Data Acquisition System (NDAS) software suite. The ability to use the software at multiple centers, even though each field center uses differing DAS hardware with different capabilities, drove a requirement that the software design be portable with minimal modifications to the software. Then, with software release requirements, evaluations, and approvals completed, the NDAS software suite could also become available to other government agencies, corporations, universities, and the general United States public.

Herbert, Phillip W., Sr.↗

Computational Heat Flux Analysis for HEATheR Electric Aircraft Wing Ice Protection Systems

Increased electrification of aircraft systems, a growing trend in the aircraft industry, affects subsystems that have historically been pneumatically driven by the engine. Optimized design of propulsion and power systems must account for the requirements of these subsystems. One such subsystem, the wing ice protection system, is the focus of this paper. A preliminary computational icing analysis has been conducted using the LEWICE and ANSYS FENSAP-ICE software to characterize the requirements of a thermal ice protection system for three More Electric Aircraft concepts. This paper summarizes the methodology, simulation execution, and icing conditions used for the analysis as well as discusses the results, observed trends, and impacts to system design. This initial analysis indicates that the computed heat requirements for the wing ice protection systems are not within the capabilities of known traditional systems. A discussion of potential methods for reducing the heat flow requirement by the ice protection system is included. Potential refinements to the analysis to improve the accuracy are also discussed.

Nic Heersema↗

Seven Processes that Enable NASA Software Engineering Technologies

This slide presentation reviews seven processes that NASA uses to ensure that software is developed, acquired and maintained as specified in the NPR 7150.2A requirement. The requirement is to ensure that all software be appraised for the Capability Maturity Model Integration (CMMI). The enumerated processes are: (7) Product Integration, (6) Configuration Management, (5) Verification, (4) Software Assurance, (3) Measurement and Analysis, (2) Requirements Management and (1) Planning & Monitoring. Each of these is described and the group(s) that are responsible is described.

Housch, Helen↗

Conversion-Integration of MSFC Nonlinear Signal Diagnostic Analysis Algorithms for Realtime Execution of MSFC's MPP Prototype System

NASA's advanced propulsion system Small Scale Magnetic Disturbances/Advanced Technology Development (SSME/ATD) has been undergoing extensive flight certification and developmental testing, which involves large numbers of health monitoring measurements. To enhance engine safety and reliability, detailed analysis and evaluation of the measurement signals are mandatory to assess its dynamic characteristics and operational condition. Efficient and reliable signal detection techniques will reduce the risk of catastrophic system failures and expedite the evaluation of both flight and ground test data, and thereby reduce launch turn-around time. During the development of SSME, ASRI participated in the research and development of several advanced non- linear signal diagnostic methods for health monitoring and failure prediction in turbomachinery components. However, due to the intensive computational requirement associated with such advanced analysis tasks, current SSME dynamic data analysis and diagnostic evaluation is performed off-line following flight or ground test with a typical diagnostic turnaround time of one to two days. The objective of MSFC's MPP Prototype System is to eliminate such 'diagnostic lag time' by achieving signal processing and analysis in real-time. Such an on-line diagnostic system can provide sufficient lead time to initiate corrective action and also to enable efficient scheduling of inspection, maintenance and repair activities. The major objective of this project was to convert and implement a number of advanced nonlinear diagnostic DSP algorithms in a format consistent with that required for integration into the Vanderbilt Multigraph Architecture (MGA) Model Based Programming environment. This effort will allow the real-time execution of these algorithms using the MSFC MPP Prototype System. ASRI has completed the software conversion and integration of a sequence of nonlinear signal analysis techniques specified in the SOW for real-time execution on MSFC's MPP Prototype. This report documents and summarizes the results of the contract tasks; provides the complete computer source code; including all FORTRAN/C Utilities; and all other utilities/supporting software libraries that are required for operation.

Jong, Jen-Yi↗

A Testbed for Evaluating Lunar Habitat Autonomy Architectures

A lunar outpost will involve a habitat with an integrated set of hardware and software that will maintain a safe environment for human activities. There is a desire for a paradigm shift whereby crew will be the primary mission operators, not ground controllers. There will also be significant periods when the outpost is uncrewed. This will require that significant automation software be resident in the habitat to maintain all system functions and respond to faults. JSC is developing a testbed to allow for early testing and evaluation of different autonomy architectures. This will allow evaluation of different software configurations in order to: 1) understand different operational concepts; 2) assess the impact of failures and perturbations on the system; and 3) mitigate software and hardware integration risks. The testbed will provide an environment in which habitat hardware simulations can interact with autonomous control software. Faults can be injected into the simulations and different mission scenarios can be scripted. The testbed allows for logging, replaying and re-initializing mission scenarios. An initial testbed configuration has been developed by combining an existing life support simulation and an existing simulation of the space station power distribution system. Results from this initial configuration will be presented along with suggested requirements and designs for the incremental development of a more sophisticated lunar habitat testbed.

Lawler, Dennis G.↗

Expert system verification and validation study. Phase 2: Requirements Identification. Delivery 2: Current requirements applicability

The second phase of a task is described which has the ultimate purpose of ensuring that adequate Expert Systems (ESs) Verification and Validation (V and V) tools and techniques are available for Space Station Freedom Program Knowledge Based Systems development. The purpose of this phase is to recommend modifications to current software V and V requirements which will extend the applicability of the requirements to NASA ESs.

Source record↗

Towards a software profession

An increasing number of programmers have attempted to change their image. They have made it plain that they wish not only to be taken seriously, but they also wish to be regarded as professionals. Many programmers now wish to referred to as software engineers. If programmers wish to be considered professionals in every sense of the word, two obstacles must be overcome: the inability to think of software as a product, and the idea that little or no skill is required to create and handle software throughout its life cycle. The steps to be taken toward professionalization are outlined along with recommendations.

Berard, Edward V.↗