Engineering Papers⌕ Search

SEARCH · Engineering Papers

Results for “software software requirements quality”

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 307 records · Page 17

NALNET book system: Cost benefit study

The goals of the NASA's library network system, NALNET, the functions of the current book system, the products and services of a book system required by NASA Center libraries, and the characteristics of a system that would best supply those products and services were assessed. Emphasis was placed on determining the most cost effective means of meeting NASA's requirements for an automated book system. Various operating modes were examined including the current STIMS file, the PUBFILE, developing software improvements for products as appropriate to the Center needs, and obtaining cataloging and products from the bibliographic utilities including at least OCLC, RLIN, BNA, and STIF. It is recommended that NALNET operate under the STIMS file mode and obtain cataloging and products from the bibliographic utilities. The recommendations are based on the premise that given the current state of the art in library automation it is not cost effective for NASA to maintain a full range of cataloging services on its own system. The bibliographic utilities can support higher quality systems with a greater range of services at a lower total cost.

Dewath, N. V.↗

Software Development Standard Processes (SDSP)

A JPL-created set of standard processes is to be used throughout the lifecycle of software development. These SDSPs cover a range of activities, from management and engineering activities, to assurance and support activities. These processes must be applied to software tasks per a prescribed set of procedures. JPL s Software Quality Improvement Project is currently working at the behest of the JPL Software Process Owner to ensure that all applicable software tasks follow these procedures. The SDSPs are captured as a set of 22 standards in JPL s software process domain. They were developed in-house at JPL by a number of Subject Matter Experts (SMEs) residing primarily within the Engineering and Science Directorate, but also from the Business Operations Directorate and Safety and Mission Success Directorate. These practices include not only currently performed best practices, but also JPL-desired future practices in key thrust areas like software architecting and software reuse analysis. Additionally, these SDSPs conform to many standards and requirements to which JPL projects are beholden.

Lavin, Milton L.↗

Production of Flight Instruments for Multi-Satellite Constellations

Recent National Academy of Science Decadal Surveys in space and Earth-science have called for simultaneous, distributed multi-point measurements in and from space, requiring constellations of small spacecraft. Small satellites have demonstrated their utility for enabling high-quality science measurements and observations. NASA missions have leveraged advances in sensor miniaturization, technology innovations, and new small satellite mission architectures to enable meaningful measurement-based scientific investigations that operate on small satellites and that are responsive to science objectives described in National Academy of Science Decadal Surveys. The advent of high capability small spacecraft enables consideration of science missions involving multiple small spacecraft, constellations of a few or many for simultaneous distributed in situ observations or remote observations from a variety of viewpoints. The central challenge for fielding instrumented space-flight constellations is to provide the required multiple sets of fully verified and calibrated instrument hardware, software, and operational processes from within a one-off project-based scientific space flight culture. Although there are numerous commercial entities providing “off-the shelf” spacecraft and avionics, the challenge lies in the multi-unit production of the uniquely targeted instrumentation necessary to perform the specific measurements required for a particular science investigation. Traditionally, the cost of such instrumentation has represented a significant portion of the hardware cost for a mission and posed the highest risk area for implementation. A shift in paradigm from large science platforms to constellations of smaller satellites drives the challenge to build instruments in a quasi-production environment. This paper describes key aspects of, and challenges encountered in the development program for the successful production of instruments for the Fast-Plasma Investigation (FPI) instrument suite of 64 flight plasma spectrometers and supporting electronics on the NASA Magnetospheric Multiscale (MMS) 4 satellite constellation mission. Although the MMS mission was not composed of small satellites, there are key aspects of the instrument production that apply directly to constellations of small satellites.

Arthur D Jacques↗

Problem Complexity and LLM: H-M Team Reliability in Challenging Environments

In traditional human-machine operations, the functional decomposition of actions and responsibilities among various agents is assigned a priori. For instance, in current air traffic operations, although assisted by software, human pilots have the ultimate control of aircraft. Multiagent human-machine and machine-machine systems will face problems of varying and potentially unpredicted complexity in future challenging scenarios of planetary, en route, and orbital activities. Hence, it is important to enable dynamic transfer of decision-making to appropriate team members, human or machine, depending on which agent is best equipped to solve that specific problem on a time budget. In this paper, we consider aspects of problem-solving and its modeling that affect the outcomes of decision-making as a function of solution quality and the likelihood of solving the problem on a required time budget. We focus on Large Language Models (LLM) as potential machine teammates and conclude that practical, predictive modeling of their performance, at the current stage of their development, is infeasible. Simple examples help us illustrate that current LLM will require fundamental advancements to provide reliable support in team decision-making, especially in safety-critical and time-critical domains. The study is not meant to diminish the value of the remarkable capabilities of LLM, but rather to gain a better understanding of the technology’s appropriate use and the needed additions.

function allocation↗

Production of Flight Instruments for Multi-Satellite Constellations

Recent National Academy of Science Decadal Surveys in space and Earth-science have called for simultaneous, distributed multi-point measurements in and from space, requiring constellations of small spacecraft. Small satellites have demonstrated their utility for enabling high-quality science measurements and observations. NASA missions have leveraged advances in sensor miniaturization, technology innovations, and new small satellite mission architectures to enable meaningful measurement-based scientific investigations that operate on small satellites and that are responsive to science objectives described in National Academy of Science Decadal Surveys. The advent of high capability small spacecraft enables consideration of science missions involving multiple small spacecraft, constellations of a few or many for simultaneous distributed in situ observations or remote observations from a variety of viewpoints. The central challenge for fielding instrumented space-flight constellations is to provide the required multiple sets of fully verified and calibrated instrument hardware, software, and operational processes from within a one-off project-based scientific space flight culture. Although there are numerous commercial entities providing “off-the shelf” spacecraft and avionics, the challenge lies in the multi-unit production of the uniquely targeted instrumentation necessary to perform the specific measurements required for a particular science investigation. Traditionally, the cost of such instrumentation has represented a significant portion of the hardware cost for a mission and posed the highest risk area for implementation. A shift in paradigm from large science platforms to constellations of smaller satellites drives the challenge to build instruments in a quasi-production environment. This paper describes key aspects of, and challenges encountered in the development program for the successful production of instruments for the Fast-Plasma Investigation (FPI) instrument suite of 64 flight plasma spectrometers and supporting electronics on the NASA Magnetospheric Multiscale (MMS) 4 satellite constellation mission. Although the MMS mission was not composed of small satellites, there are key aspects of the instrument production that apply directly to constellations of small satellites.

Arthur D Jacques↗

TransFit: Finite element analysis data fitting software

The Advanced X-Ray Astrophysics Facility (AXAF) mission support team has made extensive use of geometric ray tracing to analyze the performance of AXAF developmental and flight optics. One important aspect of this performance modeling is the incorporation of finite element analysis (FEA) data into the surface deformations of the optical elements. TransFit is software designed for the fitting of FEA data of Wolter I optical surface distortions with a continuous surface description which can then be used by SAO's analytic ray tracing software, currently OSAC (Optical Surface Analysis Code). The improved capabilities of Transfit over previous methods include bicubic spline fitting of FEA data to accommodate higher spatial frequency distortions, fitted data visualization for assessing the quality of fit, the ability to accommodate input data from three FEA codes plus other standard formats, and options for alignment of the model coordinate system with the ray trace coordinate system. TransFit uses the AnswerGarden graphical user interface (GUI) to edit input parameters and then access routines written in PV-WAVE, C, and FORTRAN to allow the user to interactively create, evaluate, and modify the fit. The topics covered include an introduction to TransFit: requirements, designs philosophy, and implementation; design specifics: modules, parameters, fitting algorithms, and data displays; a procedural example; verification of performance; future work; and appendices on online help and ray trace results of the verification section.

Freeman, Mark↗

Web Application Software for Ground Operations Planning Database (GOPDb) Management

A Web application facilitates collaborative development of the ground operations planning document. This will reduce costs and development time for new programs by incorporating the data governance, access control, and revision tracking of the ground operations planning data. Ground Operations Planning requires the creation and maintenance of detailed timelines and documentation. The GOPDb Web application was created using state-of-the-art Web 2.0 technologies, and was deployed as SaaS (Software as a Service), with an emphasis on data governance and security needs. Application access is managed using two-factor authentication, with data write permissions tied to user roles and responsibilities. Multiple instances of the application can be deployed on a Web server to meet the robust needs for multiple, future programs with minimal additional cost. This innovation features high availability and scalability, with no additional software that needs to be bought or installed. For data governance and security (data quality, management, business process management, and risk management for data handling), the software uses NAMS. No local copy/cloning of data is permitted. Data change log/tracking is addressed, as well as collaboration, work flow, and process standardization. The software provides on-line documentation and detailed Web-based help. There are multiple ways that this software can be deployed on a Web server to meet ground operations planning needs for future programs. The software could be used to support commercial crew ground operations planning, as well as commercial payload/satellite ground operations planning. The application source code and database schema are owned by NASA.

Lanham, Clifton↗

ISS Double-Gimbaled CMG Subsystem Simulation Using the Agile Development Method

This paper presents an evolutionary approach in simulating a cluster of 4 Control Moment Gyros (CMG) on the International Space Station (ISS) using a common sense approach (the agile development method) for concurrent mathematical modeling and simulation of the CMG subsystem. This simulation is part of Training systems for the 21st Century simulator which will provide training for crew members, instructors, and flight controllers. The basic idea of how the CMGs on the space station are used for its non-propulsive attitude control is briefly explained to set up the context for simulating a CMG subsystem. Next different reference frames and the detailed equations of motion (EOM) for multiple double-gimbal variable-speed control moment gyroscopes (DGVs) are presented. Fixing some of the terms in the EOM becomes the special case EOM for ISS's double-gimbaled fixed speed CMGs. CMG simulation development using the agile development method is presented in which customer's requirements and solutions evolve through iterative analysis, design, coding, unit testing and acceptance testing. At the end of the iteration a set of features implemented in that iteration are demonstrated to the flight controllers thus creating a short feedback loop and helping in creating adaptive development cycles. The unified modeling language (UML) tool is used in illustrating the user stories, class designs and sequence diagrams. This incremental development approach of mathematical modeling and simulating the CMG subsystem involved the development team and the customer early on, thus improving the quality of the working CMG system in each iteration and helping the team to accurately predict the cost, schedule and delivery of the software.

Inampudi, Ravi↗

Systems, methods and apparatus for modeling, specifying and deploying policies in autonomous and autonomic systems using agent-oriented software engineering

Systems, methods and apparatus are provided through which in some embodiments, an agent-oriented specification modeled with MaCMAS, is analyzed, flaws in the agent-oriented specification modeled with MaCMAS are corrected, and an implementation is derived from the corrected agent-oriented specification. Described herein are systems, method and apparatus that produce fully (mathematically) tractable development of agent-oriented specification(s) modeled with methodology fragment for analyzing complex multiagent systems (MaCMAS) and policies for autonomic systems from requirements through to code generation. The systems, method and apparatus described herein are illustrated through an example showing how user formulated policies can be translated into a formal mode which can then be converted to code. The requirements-based programming systems, method and apparatus described herein may provide faster, higher quality development and maintenance of autonomic systems based on user formulation of policies.

Hinchey, Michael G.↗

Control of Technology Transfer at JPL

Controlled Technology: 1) Design: preliminary or critical design data, schematics, technical flow charts, SNV code/diagnostics, logic flow diagrams, wirelist, ICDs, detailed specifications or requirements. 2) Development: constraints, computations, configurations, technical analyses, acceptance criteria, anomaly resolution, detailed test plans, detailed technical proposals. 3) Production: process or how-to: assemble, operated, repair, maintain, modify. 4) Manufacturing: technical instructions, specific parts, specific materials, specific qualities, specific processes, specific flow. 5) Operations: how-to operate, contingency or standard operating plans, Ops handbooks. 6) Repair: repair instructions, troubleshooting schemes, detailed schematics. 7) Test: specific procedures, data, analysis, detailed test plan and retest plans, detailed anomaly resolutions, detailed failure causes and corrective actions, troubleshooting, trended test data, flight readiness data. 8) Maintenance: maintenance schedules and plans, methods for regular upkeep, overhaul instructions. 9) Modification: modification instructions, upgrades kit parts, including software

Jet Propulsion Laboratory (JPL)↗

Investigation into the Use of the Concept Laser QM System as an In-Situ Research and Evaluation Tool

The NASA Marshall Space Flight Center (MSFC) is using a Concept Laser Fusing (Cusing) M2 powder bed additive manufacturing system for the build of space flight prototypes and hardware. NASA MSFC is collecting and analyzing data from the M2 QM Meltpool and QM Coating systems for builds. This data is intended to aide in understanding of the powder-bed additive manufacturing process, and in the development of a thermal model for the process. The QM systems are marketed by Concept Laser GmbH as in-situ quality management modules. The QM Meltpool system uses both a high-speed near-IR camera and a photodiode to monitor the melt pool generated by the laser. The software determines from the camera images the size of the melt pool. The camera also measures the integrated intensity of the IR radiation, and the photodiode gives an intensity value based on the brightness of the melt pool. The QM coating system uses a high resolution optical camera to image the surface after each layer has been formed. The objective of this investigation was to determine the adequacy of the QM Meltpool system as a research instrument for in-situ measurement of melt pool size and temperature and its applicability to NASA's objectives in (1) Developing a process thermal model and (2) Quantifying feedback measurements with the intent of meeting quality requirements or specifications. Note that Concept Laser markets the system only as capable of giving an indication of changes between builds, not as an in-situ research and evaluation tool. A secondary objective of the investigation is to determine the adequacy of the QM Coating system as an in-situ layer-wise geometry and layer quality evaluation tool.

Bagg, Stacey↗

Capturing, using, and managing quality assurance knowledge for shuttle post-MECO flight design

Ascent initialization values used by the Shuttle's onboard computer for nominal and abort mission scenarios are verified by a six degrees of freedom computer simulation. The procedure that the Ascent Post Main Engine Cutoff (Post-MECO) group uses to perform quality assurance (QA) of the simulation is time consuming. Also, the QA data, checklists and associated rationale, though known by the group members, is not sufficiently documented, hindering transfer of knowledge and problem resolution. A new QA procedure which retains the current high level of integrity while reducing the time required to perform QA is needed to support the increasing Shuttle flight rate. Documenting the knowledge is also needed to increase its availability for training and problem resolution. To meet these needs, a knowledge capture process, embedded into the group activities, was initiated to verify the existing QA checks, define new ones, and document all rationale. The resulting checks were automated in a conventional software program to achieve the desired standardization, integrity, and time reduction. A prototype electronic knowledge base was developed with Macintosh's HyperCard to serve as a knowledge capture tool and data storage.

Peters, H. L.↗

Spiral model pilot project information model

The objective was an evaluation of the Spiral Model (SM) development approach to allow NASA Marshall to develop an experience base of that software management methodology. A discussion is presented of the Information Model (IM) that was used as part of the SM methodology. A key concept of the SM is the establishment of an IM to be used by management to track the progress of a project. The IM is the set of metrics that is to be measured and reported throughout the life of the project. These metrics measure both the product and the process to ensure the quality of the final delivery item and to ensure the project met programmatic guidelines. The beauty of the SM, along with the IM, is the ability to measure not only the correctness of the specification and implementation of the requirements but to also obtain a measure of customer satisfaction.

Source record↗

Web-Based Real-Time Emergency Monitoring

The Web-based Real-Time Asset Monitoring (RAM) module for emergency operations and facility management enables emergency personnel in federal agencies and local and state governments to monitor and analyze data in the event of a natural disaster or other crisis that threatens a large number of people and property. The software can manage many disparate sources of data within a facility, city, or county. It was developed on industry-standard Geo- Spatial software and is compliant with open GIS standards. RAM View can function as a standalone system, or as an integrated plugin module to Emergency Operations Center (EOC) software suites such as REACT (Real-time Emergency Action Coordination Tool), thus ensuring the widest possible distribution among potential users. RAM has the ability to monitor various data sources, including streaming data. Many disparate systems are included in the initial suite of supported hardware systems, such as mobile GPS units, ambient measurements of temperature, moisture and chemical agents, flow meters, air quality, asset location, and meteorological conditions. RAM View displays real-time data streams such as gauge heights from the U.S. Geological Survey gauging stations, flood crests from the National Weather Service, and meteorological data from numerous sources. Data points are clearly visible on the map interface, and attributes as specified in the user requirements can be viewed and queried.

Harvey, Craig A.↗

Digital Fly-By-Wire Flight Control Validation Experience

The experience gained in digital fly-by-wire technology through a flight test program being conducted by the NASA Dryden Flight Research Center in an F-8C aircraft is described. The system requirements are outlined, along with the requirements for flight qualification. The system is described, including the hardware components, the aircraft installation, and the system operation. The flight qualification experience is emphasized. The qualification process included the theoretical validation of the basic design, laboratory testing of the hardware and software elements, systems level testing, and flight testing. The most productive testing was performed on an iron bird aircraft, which used the actual electronic and hydraulic hardware and a simulation of the F-8 characteristics to provide the flight environment. The iron bird was used for sensor and system redundancy management testing, failure modes and effects testing, and stress testing in many cases with the pilot in the loop. The flight test program confirmed the quality of the validation process by achieving 50 flights without a known undetected failure and with no false alarms.

Szalai, K. J.↗

Simulink-Based Simulation Architecture for Evaluating Controls for Aerospace Vehicles (SAREC-ASV)

The Simulation Architecture for Evaluating Controls for Aerospace Vehicles (SAREC-ASV) is a Simulink-based approach to providing an engineering quality desktop simulation capability for finding trim solutions, extracting linear models for vehicle analysis and control law development, and generating open-loop and closed-loop time history responses for control system evaluation. It represents a useful level of maturity rather than a finished product. The layout is hierarchical and supports concurrent component development and validation, with support from the Concurrent Versions System (CVS) software management tool. Real Time Workshop (RTW) is used to generate pre-compiled code for substantial component modules, and templates permit switching seamlessly between original Simulink and code compiled for various platforms. Two previous limitations are addressed. Turn around time for incorporating tabular model components was improved through auto-generation of required Simulink diagrams based on data received in XML format. The layout was modified to exploit a Simulink "compile once, evaluate multiple times" capability for zero elapsed time for use in trimming and linearizing. Trim is achieved through a Graphical User Interface (GUI) with a narrow, script definable interface to the vehicle model which facilitates incorporating new models.

Christhilf, David m.↗

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↗

Software Formal Inspections Guidebook

The Software Formal Inspections Guidebook is designed to support the inspection process of software developed by and for NASA. This document provides information on how to implement a recommended and proven method for conducting formal inspections of NASA software. This Guidebook is a companion document to NASA Standard 2202-93, Software Formal Inspections Standard, approved April 1993, which provides the rules, procedures, and specific requirements for conducting software formal inspections. Application of the Formal Inspections Standard is optional to NASA program or project management. In cases where program or project management decide to use the formal inspections method, this Guidebook provides additional information on how to establish and implement the process. The goal of the formal inspections process as documented in the above-mentioned Standard and this Guidebook is to provide a framework and model for an inspection process that will enable the detection and elimination of defects as early as possible in the software life cycle. An ancillary aspect of the formal inspection process incorporates the collection and analysis of inspection data to effect continual improvement in the inspection process and the quality of the software subjected to the process.

Source record↗