Search NASA⌕ Search

SEARCH · Search NASA

Results for “System 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 19 records
All sourcesNASA NTRSDOE OSTI
NASA NTRS1994

NASCOM system development plan: System description, capabilities, and plans, FY 94-2

The Nascom System Development Plan (NSDP) for FY 94-2 contains 17 sections. It is a management document containing the approved plan for maintaining the Nascom Network System. Topics covered include an overview of Nascom systems and services, major ground communication support systems, low-speed data system, voice system, high-speed data system, Nascom support for NASA networks, Nascom planning for NASA missions, and network upgrade and advanced systems developments and plans.

Source record↗
NASA NTRS1995

Nascom System Development Plan: System Description, Capabilities and Plans

The NASA Communications (Nascom) System Development Plan (NSDP), reissued annually, describes the organization of Nascom, how it obtains communication services, its current systems, its relationship with other NASA centers and International Partner Agencies, some major spaceflight projects which generate significant operational communication support requirements, and major Nascom projects in various stages of development or implementation.

Source record↗
NASA NTRS2017

Launch Control System Software Development System Automation Testing

The Spaceport Command and Control System (SCCS) is the National Aeronautics and Space Administration's (NASA) launch control system for the Orion capsule and Space Launch System, the next generation manned rocket currently in development. This system requires high quality testing that will measure and test the capabilities of the system. For the past two years, the Exploration and Operations Division at Kennedy Space Center (KSC) has assigned a group including interns and full-time engineers to develop automated tests to save the project time and money. The team worked on automating the testing process for the SCCS GUI that would use streamed simulated data from the testing servers to produce data, plots, statuses, etc. to the GUI. The software used to develop automated tests included an automated testing framework and an automation library. The automated testing framework has a tabular-style syntax, which means the functionality of a line of code must have the appropriate number of tabs for the line to function as intended. The header section contains either paths to custom resources or the names of libraries being used. The automation library contains functionality to automate anything that appears on a desired screen with the use of image recognition software to detect and control GUI components. The data section contains any data values strictly created for the current testing file. The body section holds the tests that are being run. The function section can include any number of functions that may be used by the current testing file or any other file that resources it. The resources and body section are required for all test files; the data and function sections can be left empty if the data values and functions being used are from a resourced library or another file. To help equip the automation team with better tools, the Project Lead of the Automated Testing Team, Jason Kapusta, assigned the task to install and train an optical character recognition (OCR) tool to Brandon Echols, a fellow intern, and I. The purpose of the OCR tool is to analyze an image and find the coordinates of any group of text. Some issues that arose while installing the OCR tool included the absence of certain libraries needed to train the tool and an outdated software version. We eventually resolved the issues and successfully installed the OCR tool. Training the tool required many images and different fonts and sizes, but in the end the tool learned to accurately decipher the text in the images and their coordinates. The OCR tool produced a file that contained significant metadata for each section of text, but only the text and coordinates of the text was required for our purpose. The team made a script to parse the information we wanted from the OCR file to a different file that would be used by automation functions within the automated framework. Since a majority of development and testing for the automated test cases for the GUI in question has been done using live simulated data on the workstations at the Launch Control Center (LCC), a large amount of progress has been made. As of this writing, about 60% of all of automated testing has been implemented. Additionally, the OCR tool will help make our automated tests more robust due to the tool's text recognition being highly scalable to different text fonts and text sizes. Soon we will have the whole test system automated, allowing for more full-time engineers working on development projects.

Automation↗
NASA NTRS1973

SIRU development. Volume 1: System development

A complete description of the development and initial evaluation of the Strapdown Inertial Reference Unit (SIRU) system is reported. System development documents the system mechanization with the analytic formulation for fault detection and isolation processing structure; the hardware redundancy design and the individual modularity features; the computational structure and facilities; and the initial subsystem evaluation results.

Gilmore, J. P.↗
NASA NTRS1997

Desktop Access to Full-Text NACA and NASA Reports: Systems Developed by NASA Langley Technical Library

NASA Langley Technical Library has been involved in developing systems for full-text information delivery of NACA/NASA technical reports since 1991. This paper will describe the two prototypes it has developed and the present production system configuration. The prototype systems are a NACA CD-ROM of thirty-three classic paper NACA reports and a network-based Full-text Electronic Reports Documents System (FEDS) constructed from both paper and electronic formats of NACA and NASA reports. The production system is the DigiDoc System (DIGItal Documents) presently being developed based on the experiences gained from the two prototypes. DigiDoc configuration integrates the on-line catalog database World Wide Web interface and PDF technology to provide a powerful and flexible search and retrieval system. It describes in detail significant achievements and lessons learned in terms of data conversion, storage technologies, full-text searching and retrieval, and image databases. The conclusions from the experiences of digitization and full- text access and future plans for DigiDoc system implementation are discussed.

Ambur, Manjula Y.↗
NASA NTRS1988

The Transportable Applications Environment - An interactive design-to-production development system

An account is given of the design philosophy and architecture of the Transportable Applications Environment (TAE), an executive program binding a system of applications programs into a single, easily operable whole. TAE simplifies the job of a system developer by furnishing a stable framework for system-building; it also integrates system activities, and cooperates with the host operating system in order to perform such functions as task-scheduling and I/O. The initial TAE human/computer interface supported command and menu interfaces, data displays, parameter-prompting, error-reporting, and online help. Recent extensions support graphics workstations with a window-based, modeless user interface.

Perkins, Dorothy C.↗
NASA NTRS2016

Marshall Space Flight Center Ground Systems Development and Integration

Ground Systems Development and Integration performs a variety of tasks in support of the Mission Operations Laboratory (MOL) and other Center and Agency projects. These tasks include various systems engineering processes such as performing system requirements development, system architecture design, integration, verification and validation, software development, and sustaining engineering of mission operations systems that has evolved the Huntsville Operations Support Center (HOSC) into a leader in remote operations for current and future NASA space projects. The group is also responsible for developing and managing telemetry and command configuration and calibration databases. Personnel are responsible for maintaining and enhancing their disciplinary skills in the areas of project management, software engineering, software development, software process improvement, telecommunications, networking, and systems management. Domain expertise in the ground systems area is also maintained and includes detailed proficiency in the areas of real-time telemetry systems, command systems, voice, video, data networks, and mission planning systems.

Wade, Gina↗
NASA NTRS1987

An easy-to-use diagnostic system development shell

The Diagnostic System Development Shell (DSDS), an expert system development shell for diagnostic systems, is described. The major objective of building the DSDS is to create a very easy to use and friendly environment for knowledge engineers and end-users. The DSDS is written in OPS5 and CommonLisp. It runs on a VAX/VMS system. A set of domain independent, generalized rules is built in the DSDS, so the users need not be concerned about building the rules. The facts are explicitly represented in a unified format. A powerful check facility which helps the user to check the errors in the created knowledge bases is provided. A judgement facility and other useful facilities are also available. A diagnostic system based on the DSDS system is question driven and can call or be called by other knowledge based systems written in OPS5 and CommonLisp. A prototype diagnostic system for diagnosing a Philips constant potential X-ray system has been built using the DSDS.

Tsai, L. C.↗
NASA NTRS1993

System for Anomaly and Failure Detection (SAFD) system development

The System for Anomaly and Failure Detection (SAFD) algorithm was developed as an improvement over the current redline system used in the Space Shuttle Main Engine Controller (SSMEC). Simulation tests and execution against previous hot fire tests demonstrated that the SAFD algorithm can detect engine failures as much as tens of seconds before the redline system recognized the failure. Although the current algorithm only operates during steady state conditions (engine not throttling), work is underway to expand the algorithm to work during transient conditions. This task assignment originally specified developing a platform for executing the algorithm during hot fire tests at Technology Test Bed (TTB) and installing the SAFD algorithm on that platform. Two units were built and installed in the Hardware Simulation Lab and at the TTB in December 1991. Since that time, the task primarily entailed improvement and maintenance of the systems, additional testing to prove the feasibility of the algorithm, and support of hot fire testing. This document addresses the work done since the last report of June 1992. The work on the System for Anomaly and Failure Detection during this period included improving the platform and the algorithm, testing the algorithm against previous test data and in the Hardware Simulation Lab, installing other algorithms on the system, providing support for operations at the Technology Test Bed, and providing routine maintenance.

Oreilly, D.↗
NASA NTRS1991

Risk management and expert system development methodology

A risk-based expert-system development methodology has been developed to provide guidance to managers and technical personnel and to serve as a standard for developing expert systems. Expert-system development differs from conventional software development in that the information needed to prepare system requirements for expert systems is not known at the outset of a project and is obtained by knowledge engineering methods. The paper describes the expert-system life cycle, development methodology, and the approach taken in this methodology to manage and reduce the risks in expert system development. Also examined are the risks of using and of not using a methodology, the studies undertaken to validate the provisions of the expert system development methodology, and the results of these validation studies.

Hull, Larry↗
NASA NTRS1990

Expert System Development Methodology (ESDM)

The Expert System Development Methodology (ESDM) provides an approach to developing expert system software. Because of the uncertainty associated with this process, an element of risk is involved. ESDM is designed to address the issue of risk and to acquire the information needed for this purpose in an evolutionary manner. ESDM presents a life cycle in which a prototype evolves through five stages of development. Each stage consists of five steps, leading to a prototype for that stage. Development may proceed to a conventional development methodology (CDM) at any time if enough has been learned about the problem to write requirements. ESDM produces requirements so that a product may be built with a CDM. ESDM is considered preliminary because is has not yet been applied to actual projects. It has been retrospectively evaluated by comparing the methods used in two ongoing expert system development projects that did not explicitly choose to use this methodology but which provided useful insights into actual expert system development practices and problems.

Sary, Charisse↗
NASA NTRS1982

The NASA Redox Storage System Development project, 1980

The technical accomplishments pertaining to the development of Redox systems and related technology are outlined in terms of the task elements: prototype systems development, application analyses, and supporting technology. Prototype systems development provides for a major procurement to develop an industrial capability to take the current NASA Lewis technology and go on to the design, development, and commercialization of iron-chromium Redox storage systems. Application analyses provides for the definition of application concepts and technology requirements, specific definition studies, and the identification of market sectors and their penetration potential. Supporting technology includes both in house and contractual efforts that encompass implementation of technology improvements in membranes, electrodes, reactant processing, and system design. The status of all elements is discussed.

Source record↗
NASA NTRS1985

Appendix E: Parallel Pascal development system

The Parallel Pascal Development System enables Parallel Pascal programs to be developed and tested on a conventional computer. It consists of several system programs, including a Parallel Pascal to standard Pascal translator, and a library of Parallel Pascal subprograms. The library includes subprograms for using Parallel Pascal on a parallel system with a fixed degree of parallelism, such as the Massively Parallel Processor, to conveniently manipulate arrays which have dimensions than the hardware. Programs can be conveninetly tested with small sized arrays on the conventional computer before attempting to run on a parallel system.

Source record↗
NASA NTRS2006

Proven Innovations and New Initiatives in Ground System Development: Reducing Costs in the Ground System

The state-of-the-practice for engineering and development of Ground Systems has evolved significantly over the past half decade. Missions that challenge ground system developers with significantly reduced budgets in spite of requirements for greater and previously unimagined functionality are now the norm. Making the right trades early in the mission lifecycle is one of the key factors to minimizing ground system costs. The Mission Operations Strategic Leadership Team at the Jet Propulsion Laboratory has spent the last year collecting and working through successes and failures in ground systems for application to future missions.

costs↗
NASA NTRS1990

Evaluation of a proposed expert system development methodology: Two case studies

Two expert system development projects were studied to evaluate a proposed Expert Systems Development Methodology (ESDM). The ESDM was developed to provide guidance to managers and technical personnel and serve as a standard in the development of expert systems. It was agreed that the proposed ESDM must be evaluated before it could be adopted; therefore a study was planned for its evaluation. This detailed study is now underway. Before the study began, however, two ongoing projects were selected for a retrospective evaluation. They were the Ranging Equipment Diagnostic Expert System (REDEX) and the Backup Control Mode Analysis and Utility System (BCAUS). Both projects were approximately 1 year into development. Interviews of project personnel were conducted, and the resulting data was used to prepare the retrospective evaluation. Decision models of the two projects were constructed and used to evaluate the completeness and accuracy of key provisions of ESDM. A major conclusion reached from these case studies is that suitability and risk analysis should be required for all AI projects, large and small. Further, the objectives of each stage of development during a project should be selected to reduce the next largest area of risk or uncertainty on the project.

Gilstrap, Lewey↗
NASA NTRS1984

The USL NASA PC R and D interactive presentation development system

The Interactive Presentation Development System (IPFS) is a highly interactive system for creating, editing, and displaying video presentation sequences, e.g., for developing and presenting displays of instructional material similiar to overhead transparency or slide presentations. However, since this system is PC-based, users (instructors) can step through sequences forward or backward, focusing attention to areas of the display with special cursor pointers. Additionally, screen displays may be dynamically modified during the presentation to show assignments or to answer questions, much like a traditional blackboard. This system is now implemented at the University of Southwestern Louisiana for use within the piloting phases of the NASA contract work.

Dominick, Wayne D.↗