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 181 records · Page 10
All sourcesNASA NTRSDOE OSTI
NASA NTRS1982

Spacelab software for science applications

The Spacelab onboard computer and software system offers a myriad of services and capabilities for those who wish to fly instruments without the expense of the new computers and software required for control, data manipulation, and telemetry handling. The needs of a wide variety of potential instrument developers have been taken into account in the development of standard but flexible interfaces from the computer to instruments. An early understanding of the basic software capabilities is advantageous to the potential Spacelab user as he begins his planning. This paper provides an introduction to these capabilities and gives reference to further more detailed technical information which will be needed as instrument planning and requirements mature.

Lokken, W. R.↗
NASA NTRS2023

Towards Streamlining Auditing for Compliance With Requirements in Open-Source Software at NASA

Context: NASA requires all software to meet several requirements (NPR 7150.2) depending on software criticality. The instantiation of these requirements may vary per project; however, once decided upon, projects must undergo audits to evaluate compliance with these requirements. Aim: We propose that audit effort can be reduced when requirements are realized by leveraging commonly used open-source infrastructure for version control, issue tracking and continuous integration, and the generated records are analyzed using a repository mining software tool to quantify process compliance. Method: We perform a case study in the NASA-funded Copilot project, utilizing Kaiaulu, a repository mining software tool. We define four software compliance metrics based on the Copilot’s requirements, and analyze their impact on source code quality. Results: Our work demonstrates how it is possible to leverage existing open source tools and platforms to facilitate software certification and qualification, and to streamline the auditing process required even when stringent requirements must be enforced. Conclusion: Together, both project and tool can be utilized to visualize project compliance, and metrics can be defined to more easily identify process irregularities to minimize auditing efforts. Project Repository: github.com/Copilot-Language/copilot Tool Repository: github.com/sailuh/kaiaulu

code-quality↗
NASA NTRS1988

Telerobot operator control station requirements

The operator control station of a telerobot system has unique functional and human factors requirements. It has to satisfy the needs of a truly interactive and user-friendly complex system, a telerobot system being a hybrid between a teleoperated and an autonomous system. These functional, hardware and software requirements are discussed, with explicit reference to the design objectives and constraints of the JPL/NASA Telerobot Demonstrator System.

Kan, Edwin P.↗
NASA NTRS1999

Intelligent Command and Control Systems for Satellite Ground Operations

This grant, Intelligent Command and Control Systems for Satellite Ground Operations, funded by NASA Goddard Space Flight Center, has spanned almost a decade. During this time, it has supported a broad range of research addressing the changing needs of NASA operations. It is important to note that many of NASA's evolving needs, for example, use of automation to drastically reduce (e.g., 70%) operations costs, are similar requirements in both government and private sectors. Initially the research addressed the appropriate use of emerging and inexpensive computational technologies, such as X Windows, graphics, and color, together with COTS (commercial-off-the-shelf) hardware and software such as standard Unix workstations to re-engineer satellite operations centers. The first phase of research supported by this grant explored the development of principled design methodologies to make effective use of emerging and inexpensive technologies. The ultimate performance measures for new designs were whether or not they increased system effectiveness while decreasing costs. GT-MOCA (The Georgia Tech Mission Operations Cooperative Associate) and GT-VITA (Georgia Tech Visual and Inspectable Tutor and Assistant), whose latter stages were supported by this research, explored model-based design of collaborative operations teams and the design of intelligent tutoring systems, respectively. Implemented in proof-of-concept form for satellite operations, empirical evaluations of both, using satellite operators for the former and personnel involved in satellite control operations for the latter, demonstrated unequivocally the feasibility and effectiveness of the proposed modeling and design strategy underlying both research efforts. The proof-of-concept implementation of GT-MOCA showed that the methodology could specify software requirements that enabled a human-computer operations team to perform without any significant performance differences from the standard two-person satellite operations team. GT-VITA, using the same underlying methodology, the operator function model (OFM), and its computational implementation, OFMspert, successfully taught satellite control knowledge required by flight operations team members. The tutor structured knowledge in three ways: declarative knowledge (e.g., What is this? What does it do?), procedural knowledge, and operational skill. Operational skill is essential in real-time operations. It combines the two former knowledge types, assisting a student to use them effectively in a dynamic, multi-tasking, real-time operations environment. A high-fidelity simulator of the operator interface to the ground control system, including an almost full replication of both the human-computer interface and human interaction with the dynamic system, was used in the GT-MOCA and GT-VITA evaluations. The GT-VITA empirical evaluation, conducted with a range of'novices' that included GSFC operations management, GSFC operations software developers, and new flight operations team members, demonstrated that GT-VITA effectively taught a wide range of knowledge in a succinct and engaging manner.

Mitchell, Christine M.↗
NASA NTRS1978

Tools for Embedded Computing Systems Software

A workshop was held to assess the state of tools for embedded systems software and to determine directions for tool development. A synopsis of the talk and the key figures of each workshop presentation, together with chairmen summaries, are presented. The presentations covered four major areas: (1) tools and the software environment (development and testing); (2) tools and software requirements, design, and specification; (3) tools and language processors; and (4) tools and verification and validation (analysis and testing). The utility and contribution of existing tools and research results for the development and testing of embedded computing systems software are described and assessed.

Source record↗
NASA NTRS1994

Results of a Formal Methods Demonstration Project

This paper describes the results of a cooperative study conducted by a team of researchers in formal methods at three NASA Centers to demonstrate FM techniques and to tailor them to critical NASA software systems. This pilot project applied FM to an existing critical software subsystem, the Shuttle's Jet Select subsystem (Phase I of an ongoing study). The present study shows that FM can be used successfully to uncover hidden issues in a highly critical and mature Functional Subsystem Software Requirements (FSSR) specification which are very difficult to discover by traditional means.

formal methods computer system specification compu↗
NASA NTRS1986

Concurrent extensions to the FORTRAN language for parallel programming of computational fluid dynamics algorithms

Experiments were conducted at NASA Ames Research Center to define multi-tasking software requirements for multiple-instruction, multiple-data stream (MIMD) computer architectures. The focus was on specifying solutions for algorithms in the field of computational fluid dynamics (CFD). The program objectives were to allow researchers to produce usable parallel application software as soon as possible after acquiring MIMD computer equipment, to provide researchers with an easy-to-learn and easy-to-use parallel software language which could be implemented on several different MIMD machines, and to enable researchers to list preferred design specifications for future MIMD computer architectures. Analysis of CFD algorithms indicated that extensions of an existing programming language, adaptable to new computer architectures, provided the best solution to meeting program objectives. The CoFORTRAN Language was written in response to these objectives and to provide researchers a means to experiment with parallel software solutions to CFD algorithms on machines with parallel architectures.

Weeks, Cindy Lou↗
NASA NTRS1995

Weaves as an Interconnection Fabric for ASIM's and Nanosatellites

Many of the micromachines under consideration require computer support, indeed, one of the appeals of this technology is the ability to intermix mechanical, optical, analog, and digital devices on the same substrate. The amount of computer power is rarely an issue, the sticking point is the complexity of the software required to make effective use of these devices. Micromachines are the nano-technologist's equivalent of 'golden screws'. In other words, they will be piece parts in larger assemblages. For example, a nano-satellite may be composed of stacked silicon wafers where each wafer contains hundreds to thousands of micromachines, digital controllers, general purpose computers, memories, and high-speed bus interconnects. Comparatively few of these devices will be custom designed, most will be stock parts selected from libraries and catalogs. The novelty will lie in the interconnections. For example, a digital accelerometer may be a component part in an adaptive suspension, a monitoring element embedded in the wrapper of a package, or a portion of the smart skin of a launch vehicle. In each case, this device must inter-operate with other devices and probes for the purposes of command, control, and communication. We propose a software technology called 'weaves' that will permit large collections of micromachines and their attendant computers to freely intercommunicate while preserving modularity, transparency, and flexibility. Weaves are composed of networks of communicating software components. The network, and the components comprising it, may be changed even while the software, and the devices it controls, are executing. This unusual degree of software plasticity permits micromachines to dynamically adapt the software to changing conditions and allows system engineers to rapidly and inexpensively develop special purpose software by assembling stock software components in custom configurations.

Gorlick, Michael M.↗
NASA NTRS1989

Requirements for multidisciplinary design of aerospace vehicles on high performance computers

The design of aerospace vehicles is becoming increasingly complex as the various contributing disciplines and physical components become more tightly coupled. This coupling leads to computational problems that will be tractable only if significant advances in high performance computing systems are made. Some of the modeling, algorithmic and software requirements generated by the design problem are discussed.

Voigt, Robert G.↗
NASA NTRS1991

Monitoring and control technologies for bioregenerative life support systems/CELSS

The development of a controlled Ecological Life Support System (CELSS) will require NASA to develop innovative monitoring and control technologies to operate the different components of the system. Primary effort over the past three to four years has been directed toward the development of technologies to operate a biomass production module. Computer hardware and software required to operate, collect, and summarize environmental data for a large plant growth chamber facility were developed and refined. Sensors and controls required to collect information on such physical parameters as relative humidity, temperature, irradiance, pressure, and gases in the atmosphere; and PH, dissolved oxygen, fluid flow rates, and electrical conductivity in the nutrient solutions are being developed and tested. Technologies required to produce high artificial irradiance for plant growth and those required to collect and transport natural light into a plant growth chamber are also being evaluated. Significant effort was directed towards the development and testing of a membrane nutrient delivery system required to manipulate, seed, and harvest crops, and to determine plant health prior to stress impacting plant productivity are also being researched. Tissue culture technologies are being developed for use in management and propagation of crop plants. Though previous efforts have focussed on development of technologies required to operate a biomass production module for a CELSS, current efforts are expanding to include technologies required to operate modules such as food preparation, biomass processing, and resource (waste) recovery which are integral parts of the CELSS.

Knott, William M.↗
NASA NTRS2005

Identifying Contingency Requirements using Obstacle Analysis on an Unpiloted Aerial Vehicle

This paper describes experience using Obstacle Analysis to identify contingency requirements on an unpiloted aerial vehicle. A contingency is an operational anomaly, and may or may not involve component failure. The challenges to this effort were: ( I ) rapid evolution of the system while operational, (2) incremental autonomy as capabilities were transferred from ground control to software control and (3) the eventual safety-criticality of such systems as they begin to fly over populated areas. The results reported here are preliminary but show that Obstacle Analysis helped (1) identify new contingencies that appeared as autonomy increased; (2) identify new alternatives for handling both previously known and new contingencies; and (3) investigate the continued validity of existing software requirements for contingency handling. Since many mobile, intelligent systems are built using a development process that poses the same challenges, the results appear to have applicability to other similar systems.

fault protection↗
NASA NTRS2001

Life Testing of the Hollow Cathode Plasma Contactor for the ProSEDS Mission

The Propulsive Small Expendable Deployer System (ProSEDS) mission is designed to provide an on-orbit demonstration of the electrodynamic propulsion capabilities of tethers in space. The ProSEDS experiment will be a secondary payload on a Delta 11 unmanned expendable booster. A 5-km conductive tether is attached to the Delta 11 second stage and collects current from the low Earth orbit (LEO) plasma. A hollow cathode plasma contactor emits the collected electrons from the Delta II, completing the electrical circuit with the ambient plasma. The current flowing through the tether generates thrust based on the Lorentz Force Law. The thrust will be generated opposite to the velocity vector, slowing down the spacecraft and causing it to de-orbit in approximately 14 days compared to the normal 6 months. A 10-km non-conductive tether is between the conductive tether and an endmass containing several scientific instruments. The ProSEDS mission lifetime was set at I day because most of the primary objectives can be met in that time. The extended ProSEDS mission will be for as many days as possible, until the Delta 11 second stage burns up or the tether is severed by a micrometeoroid or space debris particle. The Hollow Cathode Plasma Contactor (HCPC) unit has been designed for a 12-day mission. Because of the science requirements to measure the background ambient plasma, the HCPC must operate on a duty cycle. Later in the ProSEDS mission, the HCPC is operated in a manner to allow charging of the secondary battery. Due to the unusual operating requirements by the ProSEDS mission, a development unit of the HCPC was built for thorough testing. This developmental unit was tested for a simulated ProSEDS mission, with measurements of the ability to start and stop during the duty cycle. These tests also provided valuable data for the ProSEDS software requirements. Qualification tests of the HCPC flight hardware are also discussed.

Vaughn, Jason A.↗
NASA NTRS2006

CCSDS Time-Critical Onboard Networking Service

The Consultative Committee for Space Data Systems (CCSDS) is developing recommendations for communication services onboard spacecraft. Today many different communication buses are used on spacecraft requiring software with the same basic functionality to be rewritten for each type of bus. This impacts on the application software resulting in custom software for almost every new mission. The Spacecraft Onboard Interface Services (SOIS) working group aims to provide a consistent interface to various onboard buses and sub-networks, enabling a common interface to the application software. The eventual goal is reusable software that can be easily ported to new missions and run on a range of onboard buses without substantial modification. The system engineer will then be able to select a bus based on its performance, power, etc and be confident that a particular choice of bus will not place excessive demands on software development. This paper describes the SOIS Intra-Networking Service which is designed to enable data transfer and multiplexing of a variety of internetworking protocols with a range of quality of service support, over underlying heterogeneous data links. The Intra-network service interface provides users with a common Quality of Service interface when transporting data across a variety of underlying data links. Supported Quality of Service (QoS) elements include: Priority, Resource Reservation and Retry/Redundancy. These three QoS elements combine and map into four TCONS services for onboard data communications: Best Effort, Assured, Reserved, and Guaranteed. Data to be transported is passed to the Intra-network service with a requested QoS. The requested QoS includes the type of service, priority and where appropriate, a channel identifier. The data is de-multiplexed, prioritized, and the required resources for transport are allocated. The data is then passed to the appropriate data link for transfer across the bus. The SOIS supported data links may inherently provide the quality of service support requested by the intra-network layer. In the case where the data link does not have the required level of support, the missing functionality is added by SOIS. As a result of this architecture, re-usable software applications can be designed and used across missions thereby promoting common mission operations. In addition, the protocol multiplexing function enables the blending of multiple onboard networks. This paper starts by giving an overview of the SOIS architecture in section 11, illustrating where the TCONS services fit into the overall architecture. It then describes the quality of service approach adopted, in section III. The prototyping efforts that have been going on are introduced in section JY. Finally, in section V the current status of the CCSDS recommendations is summarized.

Parkes, Steve↗
NASA NTRS1976

SMS crew station (C and D panels and forward structures). CEI part 1: Detail specification, type 1 data

Established are the requirements for performance, design, test and qualification of one type of equipment identified as SMS C&D panels and forward structures. This CEI is used to provide all hardware and wiring necessary for the C&D panels to be properly interfaced with the computer complex/signal conversion equipment (SCE), crew station, and software requirements as defined in other CEI specifications.

Source record↗
NASA NTRS1996

An Assessment of IMPAC - Integrated Methodology for Propulsion and Airframe Controls

This report documents the work done under a NASA sponsored contract to transition to industry technologies developed under the NASA Lewis Research Center IMPAC (Integrated Methodology for Propulsion and Airframe Control) program. The critical steps in IMPAC are exercised on an example integrated flight/propulsion control design for linear airframe/engine models of a conceptual STOVL (Short Take-Off and Vertical Landing) aircraft, and MATRIXX (TM) executive files to implement each step are developed. The results from the example study are analyzed and lessons learned are listed along with recommendations that will improve the application of each design step. The end product of this research is a set of software requirements for developing a user-friendly control design tool which will automate the steps in the IMPAC methodology. Prototypes for a graphical user interface (GUI) are sketched to specify how the tool will interact with the user, and it is recommended to build the tool around existing computer aided control design software packages.

Walker, G. P.↗
NASA NTRS2004

Teleoperated Modular Robots for Lunar Operations

Solar system exploration is currently carried out by special purpose robots exquisitely designed for the anticipated tasks. However, all contingencies for in situ resource utilization (ISRU), human habitat preparation, and exploration will be difficult to anticipate. Furthermore, developing the necessary special purpose mechanisms for deployment and other capabilities is difficult and error prone. For example, the Galileo high gain antenna never opened, severely restricting the quantity of data returned by the spacecraft. Also, deployment hardware is used only once. To address these problems, we are developing teleoperated modular robots for lunar missions, including operations in transit from Earth. Teleoperation of lunar systems from Earth involves a three second speed-of-light delay, but experiment suggests that interactive operations are feasible.' Modular robots typically consist of many identical modules that pass power and data between them and can be reconfigured for different tasks providing great flexibility, inherent redundancy and graceful degradation as modules fail. Our design features a number of different hub, link, and joint modules to simplify the individual modules, lower structure cost, and provide specialized capabilities. Modular robots are well suited for space applications because of their extreme flexibility, inherent redundancy, high-density packing, and opportunities for mass production. Simple structural modules can be manufactured from lunar regolith in situ using molds or directed solar sintering. Software to direct and control modular robots is difficult to develop. We have used genetic algorithms to evolve both the morphology and control system for walking modular robots3 We are currently using evolvable system technology to evolve controllers for modular robots in the ISS glove box. Development of lunar modular robots will require software and physical simulators, including regolith simulation, to enable design and test of robot software and hardware, particularly automation software. Ready access to these simulators could provide opportunities for contest-driven development ala RoboCup (http://www.robocup.org/). Licensing of module designs could provide opportunities in the toy market and for spin-off applications.

Globus, Al↗
DOE OSTI2025

Reducing the Energy Consumption of Magnetic Resonance Imaging and Computed Tomography Scanners: Integrating Ecodesign and Sustainable Operations

This review aims to provide valuable insights into how energy consumption in magnetic resonance imaging (MRI) and computed tomography (CT) scanners can be effectively monitored, managed, and reduced, thereby contributing to more sustainable medical imaging practices. Demand for advanced imaging technologies such as MRI and CT scanners continues to increase, and understanding the resultant impact on greenhouse gas emissions requires a thorough evaluation of their energy consumption. Here, this review examines the energy monitoring and consumption characteristics of MRI and CT scanners, highlighting potential approaches for energy savings. An overview of MRI and CT principles, hardware components, and their associated energy consumption is provided. After addressing the technical aspects, the hardware and software requirements essential for accurate energy metering are detailed. Baseline measurements of energy consumption data are then provided as a foundation to understand current usage patterns and identify areas for improvement. Ongoing efforts to reduce energy consumption are categorized into 3 main strategies: operations, scanner design enhancements, and active scanning techniques, including accelerated MRI protocols. Ultimately, we emphasize that achieving sustainability in medical imaging requires collaboration across disciplines. By incorporating eco-friendly design in new imaging equipment, we can reduce the environmental impact, promote sustainability, and set a health care industry standard for a healthier planet.

62 RADIOLOGY AND NUCLEAR MEDICINE↗
DOE OSTI2025

Datum: A Scientific Metadata Catalog

The data catalog market is currently flooded with a myriad of different products, but none serve the scientific community well. There are cloud-native tools like Databricks, Snowflake,to on-premise solutions like Collibra and Datahub. The common failing of all these tools however, is their inability to serve the scientific data community directly. Most catalogs are targeted towards financial, health, or user data - not sensor or scientific domain data. They also prioritize integrations that often don’t exist or are just starting to be used in the scientific realm - all while ignoring common scientific tools and file types. Datum is a catalog which targets the scientific data directly, including the tools and networks in which those tools are used. We work with the producers and consumers of the data where they are, targeting cloud and on-premise with a focus on classified networks. Datum is an Erlang/Elixir application. Technical Features Note: The features listed below are still under development and may change, slightly, upon final delivery of the product. File Formats - Datum has the ability to read additional metadata and provides processing pipelines for the following file formats: Plain Text, PDF, LaTeX, HTML, Open Document Format (.odt), XML, CSV/TSV (and other standard delimiters), OpenDocument Database and Spreadsheets, Geo-Referenced TIFF, Common Data Format, HDF/HDF5, LabView TDMS, Excel, DeltaTables, Parquet, Apache Iceberg, Apache Hudi and many others. Metadata Collection - Scanners for the local and networked file systems and cloud storage providers. Network integration with common databases such as MSSQL and MySQL. User Plugin System - Users are able to provide either file processing, metadata extraction, or sampling plugins in the programming language of their choice. Authentication/Authorization -: OIDC integration, SCIM provisioning and EntraID integration out of the box. Full user and group management system with a “least privilege” operating mode. Governance - Customizable data governance platform; dictate and enforce required metadata, enforce data embargos, and enforce user agreements and NDAs before data access. Ability to create health checks on data, rejecting abandoned or poorly curated data and automatically removing it from the search index. Ability for users to submit corrections. Search - Semantic search is a first class citizen. No licenses to expensive, external software required. Integrated use of vectors and vector-based search allows for AI agent integration at all levels of operation. Metadata Model - Display and control data’s lineage and connections to other data and data directories. Data is modeled after a filesystem - an organization instantly recognizable and navigable by most any user. CLI and SDK - Ships with a Command Line Interface (CLI) tool and with a fully-featured Python SDK. This allows for rapid and programmatic use of Datum by every level of user. Minimal Infrastructure - Datum ships as a single executable file and can be run on any operating system and most CPU architectures. Datum has no reliance on external databases, search indexing tools, or other outside services - and it runs equally well on edge computing devices, cloud services, or in a clustered HPC environment.

darrington, john↗