SEARCH · Search NASA
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.
A redundant gimballed inertial system is described. System requirements and mechanization methods are defined and hardware and software development is described. Failure detection and isolation algorithms are presented and technology achievements described. Application of the system as a test tool for shuttle avionics concepts is outlined.
The analyses performed in the early period of the program which formed the basis of the sensor design is reviewed, along with the sensor design. The test program is outlined, listing all tests performed and the environmental exposure (simulated) for each, as applicable. Ground support equipment designed and built for assembly integration and field testing is described. The software developed during the program and the algorithms/flow diagrams which formed the bases for the software are summarized.
Factors to be considered in developing agency-wide standard administrative systems for NASA include uniformity of hardware and software; centralization vs. decentralization; risk exposure; and models for software development.
Although not computer program, SMAP DIDS written to provide systematic, NASA-wide structure for documenting information system development projects. Each DID (data item description) outlines document required for top-quality software development. When combined with management, assurance, and life cycle standards, Standards protect all parties who participate in design and operation of new information system.
A researcher proposes a cooperative effort among specialists who use or develop software for simulating and analyzing the control of flexible aerospace systems. A comparison of existing software for modeling control systems and flexible structures, applied to several example problems would be quite valuable. The comparison would indicate computational efficiency and capabilities with respect to handling nonlinearities and graphical output. Because of the diversity of applications of such software, the researcher believes that the proposed cooperative effort can transcend projects involving specific applications. Comparisons of software capability and efficiency can be made and gaps can be identified. In this way the results of the cooperative effort can provide guidance for individual projects. Several charts which outline the objectives and approach of the proposed cooperative effort are given here.
The introduction of software formal inspections (Fagan Inspections) at JPL for finding and fixing defects early in the software development life cycle are reviewed. It is estimated that, by the year 2000, some software efforts will rise to as much as 80 percent of the total. Software problems are especially important at NASA as critical flight software must be error-free. It is shown that formal inspections are particularly effective at finding and removing defects having to do with clarity, correctness, consistency, and completeness. A very significant discovery was that code audits were not as effective at finding defects as code inspections.
BUGS-4 (Bristol University Gas Scintillator-4) made its maiden engineering flight from Fort Summer (NM) on the 29th of September 1993. The instrument was consumed by fire after striking a power line during landing following 24 hours at float. The analysis of the telemetered data from this sophisticated instrument is a demanding task. Early analysis was compromised by electronic artifacts. Unravelling these problems has been difficult and time consuming, especially as the flight hardware was burned beyond salvage, but is is an essential preliminary to analysis. During this report period we have concentrated on a small sub-set of data (the first 30,000 events; 90 minutes at float), and developed software algorithms to correct systematic errors. Using these corrected events we have begun to develop the analysis algorithms. Although the analysis is preliminary, and restricted to the first 30,000 events, the results are encouraging, and suggest the design concepts are well matched to this application. Further work will refine the analysis, and allow quantitative evaluation of the concepts employed in BUGS-4 for applicability to future instruments. We believe this work will justify fabrication of a new instrument employing techniques deployed on BUGS-4.
This report summarizes a ten week effort to evaluate the software development process in the Checkout and Launch Control System (CLCS) for the presence of user inclusion in the design operation. A background is presented that highlights the value of achieving usability through user inclusion, progress-to-date is described, and future work is suggested so that a user inclusive design environment can be accomplished.
Versatile digital equipment supports research, development, and maintenance. Extended aircraft interrogation and display system is general-purpose assembly of digital electronic equipment on ground for testing of digital electronic systems on advanced aircraft. Many advanced features, including multiple 16-bit microprocessors, pipeline data-flow architecture, advanced operating system, and resident software-development tools. Basic collection of software includes program for handling many types of data and for displays in various formats. User easily extends basic software library. Hardware and software interfaces to subsystems provided by user designed for flexibility in configuration to meet user's requirements.
Operating in mission-critical environments requires trusted solutions, and the preference for "tried and true" approaches presents a potential barrier to infusing innovation into mission-critical systems. This presentation explores opportunities to overcome this barrier in the software domain. It outlines specific areas of innovation in software development achieved by the Johnson Space Center (JSC) Engineering Directorate in support of NASA's major human spaceflight programs, including International Space Station, Multi-Purpose Crew Vehicle (Orion), and Commercial Crew Programs. Software engineering teams at JSC work with hardware developers, mission planners, and system operators to integrate flight vehicles, habitats, robotics, and other spacecraft elements for genuinely mission critical applications. The innovations described, including the use of NASA Core Flight Software and its associated software tool chain, can lead to software that is more affordable, more reliable, better modelled, more flexible, more easily maintained, better tested, and enabling of automation.
Developing a software product involves estimating various project parameters. This is typically done in the planning stages of the project when there is much uncertainty and very little information. Coming up with accurate estimates of effort, cost, schedule, and reliability is a critical problem faced by all software project managers. The use of estimation models and commercially available tools in conjunction with the best bottom-up estimates of software-development experts enhances the ability of a product development group to derive reasonable estimates of important project parameters. This paper describes the experience of the IBM Software Solutions (SWS) Toronto Laboratory in selecting software estimation models and tools and deploying their use to the laboratory's product development groups. It introduces the SLIM and COSTAR products, the software estimation tools selected for deployment to the product areas, and discusses the rationale for their selection. The paper also describes the mechanisms used for technology injection and tool deployment, and concludes with a discussion of important lessons learned in the technology and tool insertion process.
Presently, most computer software development in the Computational Electromagnetics (CEM) community employs the structured programming paradigm, particularly using the Fortran language. Other segments of the software community began switching to an Object-Oriented Programming (OOP) paradigm in recent years to help ease design and development of highly complex codes. This paper examines design of a time-domain numerical analysis CEM code using the OOP paradigm, comparing OOP code and structured programming code in terms of software maintenance, portability, flexibility, and speed.
Research and development in plasmas and magnetospheric environments is reported. Topics discussed include: analysis and techniques of software development; data analysis and modeling; spacecraft sheath effects; laboratory plasma flow studies; instrument development.
Very few automated tools were available to support software requirements analysis and design even though improvements in quality during these phases appear to offer the greatest leverage for improving the quality and productivity of the overall software development process. Recently, however, some such tools have appeared on the market. An industry survey, and an in-house evaluation of two commercial products by programmers and analysts was undertaken to determine which tool is the best to support programmers and analysts through life cycle development. A tool was selected for full implementation on a project, where complete analysis of software statistics over the system life cycle will determine whether or not quality and productivity improvements have actually occurred. The results of the industry survey and in-house evaluation are summarized.
Topics covered include: numerical integration techniques; thermodynamics and internal state variables; experimental lab development; comparison of models at room temperature; comparison of models at elevated temperature; and integrated software development.
The purpose of this document is to provide experience-based guidance in implementing a software process improvement program in any NASA software development or maintenance community. This guidebook details how to define, operate, and implement a working software process improvement program. It describes the concept of the software process improvement program and its basic organizational components. It then describes the structure, organization, and operation of the software process improvement program, illustrating all these concepts with specific NASA examples. The information presented in the document is derived from the experiences of several NASA software organizations, including the SEL, the SEAL, and the SORCE. Their experiences reflect many of the elements of software process improvement within NASA. This guidebook presents lessons learned in a form usable by anyone considering establishing a software process improvement program within his or her own environment. This guidebook attempts to balance general and detailed information. It provides material general enough to be usable by NASA organizations whose characteristics do not directly match those of the sources of the information and models presented herein. It also keeps the ideas sufficiently close to the sources of the practical experiences that have generated the models and information.
The implementation of reuse-based software engineering not only introduces new activities to the software development process, such as domain analysis and domain modeling, it also impacts other aspects of software engineering. Other areas of software engineering that are affected include Configuration Management, Testing, Quality Control, and Verification and Validation (V&V). Activities in each of these areas must be adapted to address the entire domain or product line rather than a specific application system. This paper discusses changes and enhancements to the V&V process, in order to adapt V&V to reuse-based software engineering.
The Software Assurance Technology Center (SATC) at NASA Goddard Space Flight Center has been investigating how projects can determine when sufficient testing has been completed. For most projects, schedules are underestimated, and the last phase of the software development, testing, must be decreased. Two questions are frequently asked: "To what extent is the software error-free? " and "How much time and effort is required to detect and remove the remaining errors? " Clearly, neither question can be answered with absolute certainty. Nonetheless, the ability to answer these questions with some acceptable level of confidence is highly desirable. First, knowing the extent to which a product is error-free, we can judge when it is time to terminate testing. Secondly, if errors are judged to be present, we can perform a cost/benefit trade-off analysis to estimate when the software will be ready for use and at what cost. This paper explains the efforts of the SATC to help projects determine what is sufficient testing and when is the most cost-effective time to stop testing.