SEARCH · Engineering Papers

Results for “system software”

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 433 records · Page 24

All sources NASA NTRS DOE OSTI

NASA NTRS1975

FORTRAN Automated Code Evaluation System (FACES) user's manual, version 2

A system which provides analysis services for FORTRAN based software systems not normally available from system software is presented. The system is not a compiler, and compiler syntax diagnostics are not duplicated. For maximum adaptation to FORTRAN dialects, the code presented to the system is assumed to be compiler acceptable. The system concentrates on acceptable FORTRAN code features which are likely to produce undesirable results and identifies potential trouble areas before they become execution time malfunctions.

Source record↗

DOE OSTI2024

SCA Tools - SCRM Value Add or Lossy Noise Machines

Software supply chain risk management (SCRM) depends upon accurate information regarding the software components that comprise any given software system. The collection of components included in a software package can be organized within a software bill of materials, or SBOM. SBOMs are ideally generated when the software components are put together, such as at compile time, but for many reasons that has not and is not always possible. For example, legacy or proprietary software packages often do not have SBOMs available to downstream consumers of that software. It’s not just end users that are affected, manufacturers themselves also must deal with this problem. To answer these questions, the market has seen the rise of several commercial software composition analysis (SCA) tools. These tools aim to peer into completed software systems, automatically identifying hidden software dependencies and looking up known vulnerabilities associated with those dependencies to enable end-users to enhance their cyber supply chain risk management processes. These tools are potentially a huge boon to end users of legacy and proprietary software – and a potential bane, depending on how accurate they are. This research asks that question – how accurate are currently available binary SCA tools – and provides answers to several other questions: What does it mean to be “accurate”? What limitations do the tools have in identifying common edge cases that take place in modern software development? Can they help you avoid a devastating supply chain attack, or is it all just noise? After researching SCA tools on the market, we identified three vendors that fit our use case and would provide analysis on compiled binaries. Using these tools, we submitted firmware for critical infrastructure devices for analysis and SBOM generation. The SBOM outputs were then cross referenced with SBOMs generated through manual analysis for comparison. In addition to the firmware samples, we also submitted edge case samples based off a popular open-source library that were specifically crafted to evaluate each tools’ ability to accurately identify components. These samples were customized to be consistent with modifications we have seen in modern software development as well as a couple that are representative of supply chain attacks.

97 MATHEMATICS AND COMPUTING↗

NASA NTRS1988

A requirements specification for a software design support system

Most existing software design systems (SDSS) support the use of only a single design methodology. A good SDSS should support a wide variety of design methods and languages including structured design, object-oriented design, and finite state machines. It might seem that a multiparadigm SDSS would be expensive in both time and money to construct. However, it is proposed that instead an extensible SDSS that directly implements only minimal database and graphical facilities be constructed. In particular, it should not directly implement tools to faciliate language definition and analysis. It is believed that such a system could be rapidly developed and put into limited production use, with the experience gained used to refine and evolve the systems over time.

Noonan, Robert E.↗

NASA NTRS1990

Network, system, and status software enhancements for the autonomously managed electrical power system breadboard. Volume 1: Project summary

This volume (1 of 4) gives a summary of the original AMPS software system configuration, points out some of the problem areas in the original software design that this project is to address, and in the appendix collects all the bimonthly status reports. The purpose of AMPS is to provide a self reliant system to control the generation and distribution of power in the space station. The software in the AMPS breadboard can be divided into three levels: the operating environment software, the protocol software, and the station specific software. This project deals only with the operating environment software and the protocol software. The present station specific software will not change except as necessary to conform to new data formats.

Mckee, James W.↗

NASA NTRS2011

NASA's Advanced Multimission Operations System: A Case Study in Formalizing Software Architecture Evolution

All software systems of significant size and longevity eventually undergo changes to their basic architectural structure. Such changes may be prompted by evolving requirements, changing technology, or other reasons. Whatever the cause, software architecture evolution is commonplace in real world software projects. Recently, software architecture researchers have begun to study this phenomenon in depth. However, this work has suffered from problems of validation; research in this area has tended to make heavy use of toy examples and hypothetical scenarios and has not been well supported by real world examples. To help address this problem, I describe an ongoing effort at the Jet Propulsion Laboratory to re-architect the Advanced Multimission Operations System (AMMOS), which is used to operate NASA's deep-space and astrophysics missions. Based on examination of project documents and interviews with project personnel, I describe the goals and approach of this evolution effort and then present models that capture some of the key architectural changes. Finally, I demonstrate how approaches and formal methods from my previous research in architecture evolution may be applied to this evolution, while using languages and tools already in place at the Jet Propulsion Laboratory.

software architecture evolution↗

NASA NTRS1983

Forecasting trends in NASA flight software development tools

The experience gained in the design and development of Shuttle flight and ground support embedded software systems along with projections of increasing role and size of software in the proposed Space Station and other future NASA projects provides the basis for forecasting substantial changes in the tools and methodologies by which embedded software systems are developed and acquired. Similar changes in software architectures and operator interfaces will lead to substantial changes in the approach and techniques involved in software test and system integration. Increasing commonality among different flight systems and between flight and supporting ground systems is projected, along with a more distributed approach to software acquisition in highly complex projects such as Space Station.

Garman, J. R.↗

DOE OSTI2015

Personal Alarm System

Software that runs on smartphones and desktop web browsers and notifies border officials of radiation alarms. It displays images and data associated with an alarm and provides a variety of reports. DOE had a need for discrete notification. PAS replaces the lights and sounds of a Radiation Portal Monitor.

Source record↗

NASA NTRS2011

Observation Scheduling System

Software has been designed to schedule remote sensing with the Earth Observing One spacecraft. The software attempts to satisfy as many observation requests as possible considering each against spacecraft operation constraints such as data volume, thermal, pointing maneuvers, and others. More complex constraints such as temperature are approximated to enable efficient reasoning while keeping the spacecraft within safe limits. Other constraints are checked using an external software library. For example, an attitude control library is used to determine the feasibility of maneuvering between pairs of observations. This innovation can deal with a wide range of spacecraft constraints and solve large scale scheduling problems like hundreds of observations and thousands of combinations of observation sequences.

Chien, Steve A.↗

NASA NTRS2007

KLASS: Kennedy Launch Academy Simulation System

Software provides access to many sophisticated scientific instrumentation (Scanning Electron Microscope (SEM), a Light Microscope, a Scanning Probe Microscope (covering Scanning Tunneling, Atomic Force, and Magnetic Force microscopy), and an Energy Dispersive Spectrometer for the SEM). Flash animation videos explain how each of the instruments work. Videos on how they are used at NASA and the sample preparation. Measuring and labeling tools provided with each instrument. Hands on experience of controlling the virtual instrument to conduct investigations, much like the real scientists at NASA do. Very open architecture. Open source on SourceForge. Extensive use of XML Target audience is high school and entry-level college students. "Many beginning students never get closer to an electron microscope than the photos in their textbooks. But anyone can get a sense of what the instrument can do by downloading this simulator from NASA's Kennedy Space Center." Science Magazine, April 8th, 2005

Garner, Lesley C.↗

NASA NTRS1985

ARROWSMITH-P: A prototype expert system for software engineering management

Although the field of software engineering is relatively new, it can benefit from the use of expert systems. Two prototype expert systems were developed to aid in software engineering management. Given the values for certain metrics, these systems will provide interpretations which explain any abnormal patterns of these values during the development of a software project. The two systems, which solve the same problem, were built using different methods, rule-based deduction and frame-based abduction. A comparison was done to see which method was better suited to the needs of this field. It was found that both systems performed moderately well, but the rule-based deduction system using simple rules provided more complete solutions than did the frame-based abduction system.

Basili, Victor R.↗

NASA NTRS1985

DEASEL: An expert system for software engineering

For the past ten year, the Software Engineering Laboratory (SEL) has been collecting data on software projects carried out in the Systems Development Branch of the Flight Dynamics Division at NASA's Goddard Space Flight Center. Through a series of studies using this data, much knowledge has been gained on how software is developed within this environment. Two years ago work began on a software tool which would make this knowledge readily available to software managers. Ideally, the Dynamic Management Information Tool (DynaMITe) will aid managers in comparison across projects, prediction of a project's future, and assessment of a project's current state. This paper describes an effort to create the assessment portion of DynaMITe, called the DynaMITe Expert Advisor for the SEL (DEASEL).

Valett, J. D.↗

NASA NTRS1991

Army-NASA aircrew/aircraft integration program: Phase 4 A(3)I Man-Machine Integration Design and Analysis System (MIDAS) software detailed design document

The Man-Machine Integration Design and Analysis System (MIDAS) is an integrated suite of software components that constitutes a prototype workstation to aid designers in applying human factors principles to the design of complex human-machine systems. MIDAS is intended to be used at the very early stages of conceptual design to provide an environment wherein designers can use computational representations of the crew station and operator, instead of hardware simulators and man-in-the-loop studies, to discover problems and ask 'what if' questions regarding the projected mission, equipment, and environment. This document is the Software Product Specification for MIDAS. Introductory descriptions of the processing requirements, hardware/software environment, structure, I/O, and control are given in the main body of the document for the overall MIDAS system, with detailed discussion of the individual modules included in Annexes A-J.

Banda, Carolyn↗

NASA NTRS1996

NASA Approach to HPCCP Support Software and Tools

The NASA HPCC Program, together with other agencies participating in the Federal HPCC Program, intends to advance technologies to enable the execution of grand challenge applications at sustained rates up to TeraFLOPS. During 1995-6 NASA undertook two major systems software efforts to improve the state of high performance support software and tools. The first of these activities was a replanning of support software and tools activities internal to the Agency. In replanning the software activities emphasis was placed on Meeting the needs of Grand Challenge Uses Few projects Near term useful results. The revised NASA plan calls for support software and tools activities in four areas: Application Creation Process Support Application Usage/Operations Support Advanced Support Software and Tools Concepts Metrics Based Monitoring and Management The second major activity undertaken was participation in a multiagency Task Force resulting from the Second Pasadena Workshop on System Software and Tools. The task force developed the Guidelines for Writing System Software and Tools Requirements for Parallel and Clustered Computers.

Blaylock, Bruce↗

NASA NTRS1992

The development and technology transfer of software engineering technology at NASA. Johnson Space Center

The United State's big space projects of the next decades, such as Space Station and the Human Exploration Initiative, will need the development of many millions of lines of mission critical software. NASA-Johnson (JSC) is identifying and developing some of the Computer Aided Software Engineering (CASE) technology that NASA will need to build these future software systems. The goal is to improve the quality and the productivity of large software development projects. New trends are outlined in CASE technology and how the Software Technology Branch (STB) at JSC is endeavoring to provide some of these CASE solutions for NASA is described. Key software technology components include knowledge-based systems, software reusability, user interface technology, reengineering environments, management systems for the software development process, software cost models, repository technology, and open, integrated CASE environment frameworks. The paper presents the status and long-term expectations for CASE products. The STB's Reengineering Application Project (REAP), Advanced Software Development Workstation (ASDW) project, and software development cost model (COSTMODL) project are then discussed. Some of the general difficulties of technology transfer are introduced, and a process developed by STB for CASE technology insertion is described.

Pitman, C. L.↗

NASA NTRS1998

Towards a Theory for Integration of Mathematical Verification and Empirical Testing

From the viewpoint of a project manager responsible for the V&V (verification and validation) of a software system, mathematical verification techniques provide a possibly useful orthogonal dimension to otherwise standard empirical testing. However, the value they add to an empirical testing regime both in terms of coverage and in fault detection has been difficult to quantify. Furthermore, potential cost savings from replacing testing with mathematical verification techniques cannot be realized until the tradeoffs and synergies can be formulated. Integration of formal verification with empirical testing is also difficult because the idealized view of mathematical verification providing a correctness proof with total coverage is unrealistic and does not reflect the limitations imposed by computational complexity of mathematical techniques. This paper first describes a framework based on software reliability and formalized fault models for a theory of software design fault detection - and hence the utility of various tools for debugging. It then describes a utility model for integrating mathematical and empirical techniques with respect to fault detection and coverage analysis. It then considers the optimal combination of black-box testing, white-box (structural) testing, and formal methods in V&V of a software system. Using case studies from NASA software systems, it then demonstrates how this utility model can be used in practice.

Lowry, Michael↗

NASA NTRS1995

TOPEX/Poseidon Precision Orbit Determination Using Combined GPS, SLR, and DORIS

TOPEX/Poseidon (T/P) is a joint spaceborne oceanographic mission of U.W. NASA and France CNES design launched August 10, 1992. The satellite has a variety tracking systems for both operational and precision orbit determination. Three precise tracking systems: Satellite Laser Ranging (SLR), Doppler Orbitography and Radiopositioning Integrated by Satellite (DORIS), and Global Positioning System (GPS) provide high quality measurements essential for reconstructing the T/P orbital height with centimeter precision. This paper presents results of simultaneously processing all three data types to exploit the inherent strength of each in a combined solution. SLR and DORIS are routinely combined to provide orbit solutions for the T/P science team. GPS orbit solutions are produced as part of the first demonstration flight of a high quality spaceborne GPS receiver. Coordinate frame and software system differences between the combined SLR/DORIS orbits and the GPS orbits induce orbital height differences of 2 to 3 centimeters. Combining the three data types within a single software system permits removal of software system differences while obtaining coordinate frame calibration information. These calibrations will aid future spaceborne GPS missions that are not complemented with SLR and/or DORIS.

TOPEX/Poseidon↗

NASA NTRS2019

High-Performance Spaceflight Computing (HPSC) Middleware Overview

High Performance Spacecraft Computing (HPSC) is a joint project between the National Aeronautics and Space Administration (NASA) and Air Force Research Lab (AFRL) to develop a high-performance multi-core radiation hardened flight processor. HPSC offers a new flight computing architecture to meet the needs of NASA missions through 2030 and beyond. Providing on the order of 100X the computational capacity of current flight processors for the same amount of power, the multicore architecture of the HPSC processor, or "Chiplet" provides unprecedented flexibility in a flight computing system by enabling the operating point to be set dynamically, trading among needs for computational performance, energy management and fault tolerance. The HPSC Chiplet is being developed by Boeing under contract to NASA, and is expected to provide prototypes in 2021. The HPSC Chiplet prototypes will be delivered with an evaluation board, system emulators, comprehensive system software, and a software development kit. In addition to the vendor deliverables, the AFRL is funding the development of a flexible Middleware to be developed by NASA Jet Propulsion Laboratory and NASA Goddard Space Flight Center. The HPSC Middleware provides a suite of thirteen high level services to manage the compute, memory and I/O resources of this complex device.This presentation will provide an overview of the HPSC project, including a hardware overview, system software overview, Middleware overview, and mission use cases. The hardware overview will provide a look at the 8 core High Performance Processing Subsystem (HPPS), the Real Time Processing Subsystem (RTPS), the Chiplet Configuration Management Subsystem, on chip peripherals, and high speed I/O. The system software overview will introduce the boot loaders, operating systems, device drivers, and software development environment. The Middleware overview will provide insight into the high-level services that will be provided to help mission developers manage the many resources and configurations made possible with the Chiplet. Finally, the presentation will provide a brief look at the mission use cases that can be enabled with this next generation architecture.

middleware↗

NASA NTRS1990

A status report on the analysis of the NOAA-9 SBUV/2 sweep mode solar irradiance data

Monitoring of the near ultraviolet (UV) solar irradiance is important because the solar UV radiation is the primary energy source in the upper atmosphere. The solar irradiance at wavelengths shortward of roughly 300 nm heats the stratosphere via photodissociation of ozone in the Hartley bands. Shortward of 242 nm the solar UV flux photodissociates O2, which is then available for ozone formation. Upper stratosphere ozone variations coincident with UV solar rotational modulation have been previously reported (Gille et al., 1984). Clearly, short and long term solar irradiance observations are necessary to separate solar-forced ozone variations from anthropogenic changes. The SBUV/2 instrument onboard the NOAA-9 spacecraft has made daily measurements of the solar spectral irradiance at approximately 0.15 nm intervals in the wavelength region 160-405 nm at 1 nm resolution since March 1985. These data are not needed to determine the terrestrial ozone overburden or altitude profile, and hence are not utilized in the NOAA Operational Ozone Product System (OOPS). Therefore, assisted by the ST System Corporation, NASA has developed a scientific software system to process the solar sweep mode data from the NOAA-9 instrument. This software will also be used to process the sweep mode solar irradiance data from the NOAA-11 and later SBUV/2 instruments. An overview of the software system and a brief discussion of analysis findings to date are provided. Several outstanding concerns/problems are also presented.

Cebula, R. P.↗