Engineering Papers⌕ Search

SEARCH · Engineering Papers

Results for “design 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.

Quote a phrase for an exact phrase match. Source license links do not imply unrestricted reuse.

At least 685 records · Page 38

Methodology for Designing Fault-Protection Software

A document describes a methodology for designing fault-protection (FP) software for autonomous spacecraft. The methodology embodies and extends established engineering practices in the technical discipline of Fault Detection, Diagnosis, Mitigation, and Recovery; and has been successfully implemented in the Deep Impact Spacecraft, a NASA Discovery mission. Based on established concepts of Fault Monitors and Responses, this FP methodology extends the notion of Opinion, Symptom, Alarm (aka Fault), and Response with numerous new notions, sub-notions, software constructs, and logic and timing gates. For example, Monitor generates a RawOpinion, which graduates into Opinion, categorized into no-opinion, acceptable, or unacceptable opinion. RaiseSymptom, ForceSymptom, and ClearSymptom govern the establishment and then mapping to an Alarm (aka Fault). Local Response is distinguished from FP System Response. A 1-to-n and n-to- 1 mapping is established among Monitors, Symptoms, and Responses. Responses are categorized by device versus by function. Responses operate in tiers, where the early tiers attempt to resolve the Fault in a localized step-by-step fashion, relegating more system-level response to later tier(s). Recovery actions are gated by epoch recovery timing, enabling strategy, urgency, MaxRetry gate, hardware availability, hazardous versus ordinary fault, and many other priority gates. This methodology is systematic, logical, and uses multiple linked tables, parameter files, and recovery command sequences. The credibility of the FP design is proven via a fault-tree analysis "top-down" approach, and a functional fault-mode-effects-and-analysis via "bottoms-up" approach. Via this process, the mitigation and recovery strategy(s) per Fault Containment Region scope (width versus depth) the FP architecture.

Barltrop, Kevin↗

Averting Denver Airports on a Chip

As a result of recent advances in software engineering capabilities, we are now in a more stable environment. De-facto hardware and software standards are emerging. Work on software architecture and design patterns signals a consensus on the importance of early system-level design decisions, and agreements on the uses of certain paradigmatic software structures. We now routinely build systems that would have been risky or infeasible a few years ago. Unfortunately, technological developments threaten to destabilize software design again. Systems designed around novel computing and peripheral devices will spark ambitious new projects that will stress current software design and engineering capabilities. Micro-electro-mechanical systems (MEMS) and related technologies provide the physical basis for new systems with the potential to produce this kind of destabilizing effect. One important response to anticipated software engineering and design difficulties is carefully directed engineering-scientific research. Two specific problems meriting substantial research attention are: A lack of sufficient means to build software systems by generating, extending, specializing, and integrating large-scale reusable components; and a lack of adequate computational and analytic tools to extend and aid engineers in maintaining intellectual control over complex software designs.

Sullivan, Kevin J.↗

Software Engineering Support of the Third Round of Scientific Grand Challenge Investigations: An Earth Modeling System Software Framework Strawman Design that Integrates Cactus and UCLA/UCB Distributed Data Broker

One of the most significant challenges in large-scale climate modeling, as well as in high-performance computing in other scientific fields, is that of effectively integrating many software models from multiple contributors. A software framework facilitates the integration task. both in the development and runtime stages of the simulation. Effective software frameworks reduce the programming burden for the investigators, freeing them to focus more on the science and less on the parallel communication implementation, while maintaining high performance across numerous supercomputer and workstation architectures. This document proposes a strawman framework design for the climate community based on the integration of Cactus, from the relativistic physics community, and UCLA/UCB Distributed Data Broker (DDB) from the climate community. This design is the result of an extensive survey of climate models and frameworks in the climate community as well as frameworks from many other scientific communities. The design addresses fundamental development and runtime needs using Cactus, a framework with interfaces for FORTRAN and C-based languages, and high-performance model communication needs using DDB. This document also specifically explores object-oriented design issues in the context of climate modeling as well as climate modeling issues in terms of object-oriented design.

Talbot, Bryan↗

Rotorcraft noise prediction

The purpose of this presentation is to give a general strategy for rotorcraft noise prediction. This strategy is expressed through a modular software system design rather than theoretical analysis of the aerocoustic phenomena. The crucial design choices in a software system design are the module interface definitions. An interface is the data that are passed from one module to another. A module takes data from one (input) interface and transforms it, through a prediction method, to another (output) interface. In system design, the method is less important than the interface. The two types of methods available may be braodly classified as empirical or analytical, although no method is purely one or the other. These two general approaches will be compared as they apply to rotorcraft noise prediction.

Zorumski, W. E.↗

Multidisciplinary Modeling Software for Analysis, Design, and Optimization of HRRLS Vehicles

The concept for Highly Reliable Reusable Launch Systems (HRRLS) under the NASA Hypersonics project is a two-stage-to-orbit, horizontal-take-off / horizontal-landing, (HTHL) architecture with an air-breathing first stage. The first stage vehicle is a slender body with an air-breathing propulsion system that is highly integrated with the airframe. The light weight slender body will deflect significantly during flight. This global deflection affects the flow over the vehicle and into the engine and thus the loads and moments on the vehicle. High-fidelity multi-disciplinary analyses that accounts for these fluid-structures-thermal interactions are required to accurately predict the vehicle loads and resultant response. These predictions of vehicle response to multi physics loads, calculated with fluid-structural-thermal interaction, are required in order to optimize the vehicle design over its full operating range. This contract with ResearchSouth addresses one of the primary objectives of the Vehicle Technology Integration (VTI) discipline: the development of high-fidelity multi-disciplinary analysis and optimization methods and tools for HRRLS vehicles. The primary goal of this effort is the development of an integrated software system that can be used for full-vehicle optimization. This goal was accomplished by: 1) integrating the master code, FEMAP, into the multidiscipline software network to direct the coupling to assure accurate fluid-structure-thermal interaction solutions; 2) loosely-coupling the Euler flow solver FEFLO to the available and proven aeroelasticity and large deformation (FEAP) code; 3) providing a coupled Euler-boundary layer capability for rapid viscous flow simulation; 4) developing and implementing improved Euler/RANS algorithms into the FEFLO CFD code to provide accurate shock capturing, skin friction, and heat-transfer predictions for HRRLS vehicles in hypersonic flow, 5) performing a Reynolds-averaged Navier-Stokes computation on an HRRLS configuration; 6) integrating the RANS solver with the FEAP code for coupled fluid-structure-thermal capability; and 7) integrating the existing NASA SRGULL propulsion flow path prediction software with the FEFLO software for quasi-3D propulsion flow path predictions, 8) improving and integrating into the network, an existing adjoint-based design optimization code.

Spradley, Lawrence W.↗

Develop a Model Component

During my internship at NASA, I was a model developer for Ground Support Equipment (GSE). The purpose of a model developer is to develop and unit test model component libraries (fluid, electrical, gas, etc.). The models are designed to simulate software for GSE (Ground Special Power, Crew Access Arm, Cryo, Fire and Leak Detection System, Environmental Control System (ECS), etc. ~.) before they are implemented into hardware. These models support verifying local control and remote software for End-Item Software Under Test (SUT). The model simulates the physical behavior (function, state, limits and 110) of each end-item and it's dependencies as defined in the Subsystem Interface Table, Software Requirements & Design Specification (SRDS), Ground Integrated Schematic (GIS), and System Mechanical Schematic.(SMS). The software of each specific model component is simulated through MATLAB's Simulink program. The intensiv~ model development life cycle is a.s follows: Identify source documents; identify model scope; update schedule; preliminary design review; develop model requirements; update model.. scope; update schedule; detailed design review; create/modify library component; implement library components reference; implement subsystem components; develop a test script; run the test script; develop users guide; send model out for peer review; the model is sent out for verific~tionlvalidation; if there is empirical data, a validation data package is generated; if there is not empirical data, a verification package is generated; the test results are then reviewed; and finally, the user. requests accreditation, and a statement of accreditation is prepared. Once each component model is reviewed and approved, they are intertwined together into one integrated model. This integrated model is then tested itself, through a test script and autotest, so that it can be concluded that all models work conjointly, for a single purpose. The component I was assigned, specifically, was a fluid component, a discrete pressure switch. The switch takes a fluid pressure input, and if the pressure is greater than a designated cutoff pressure, the switch would stop fluid flow.

Ensey, Tyler S.↗

Microgrid Design Toolkit (MDT) User Guide. Software v1.3.

The Microgrid Design Toolkit (MDT) supports decision analysis for new ("greenfield") microgrid designs as well as microgrids with existing infrastructure. The current version of MDT includes two main capabilities. The first capability, the Microgrid Sizing Capability (MSC), is used to determine the size and composition of a new, grid connected microgrid in the early stages of the design process. MSC is focused on developing a microgrid that is economically viable when connected to the grid. The second capability is focused on designing a microgrid for operation in islanded mode. This second capability relies on two models: the Technology Management Optimization (TMO) model and Performance Reliability Model (PRM).

42 ENGINEERING↗

A software system for laser design and analysis

A laser-material database and laser-modeling software system for designing lasers for laser-based Light Detection And Ranging (LIDAR) systems are presented. The software system consists of three basic sections: the database, laser models, and interface software. The database contains the physical parameters of laser, optical, and nonlinear materials required by laser models. The models include efficiency calculations, electrooptical component models, resonator, amplifier, and oscillator models, and miscellaneous models. The interface software provides a user-friendly interface between the user and his personal data files, the database, and models. The structure of the software system is essentially in place, while future plans call for upgrading the computer hardware and software in order to support a multiuser multitask environment.

Cross, P. L.↗

General Aviation Data Framework

The Flight Research Services Directorate at the NASA Langley Research Center (LaRC) provides development and operations services associated with three general aviation (GA) aircraft used for research experiments. The GA aircraft includes a Cessna 206X Stationair, a Lancair Colombia 300X, and a Cirrus SR22X. Since 2004, the GA Data Framework software was designed and implemented to gather data from a varying set of hardware and software sources as well as enable transfer of the data to other computers or devices. The key requirements for the GA Data Framework software include platform independence, the ability to reuse the framework for different projects without changing the framework code, graphics display capabilities, and the ability to vary the interfaces and their performance. Data received from the various devices is stored in shared memory. This paper concentrates on the object oriented software design patterns within the General Aviation Data Framework, and how they enable the construction of project specific software without changing the base classes. The issues of platform independence and multi-threading which enable interfaces to run at different frame rates are also discussed in this paper.

Blount, Elaine M.↗

FMT (Flight Software Memory Tracker) For Cassini Spacecraft-Software Engineering Using JAVA

The software engineering design of the Flight Software Memory Tracker (FMT) Tool is discussed in this paper. FMT is a ground analysis software set, consisting of utilities and procedures, designed to track the flight software, i.e., images of memory load and updatable parameters of the computers on-board Cassini spacecraft. FMT is implemented in Java.

Flight Software Cassini↗

Design Requirements and Software Specification for the Autonomous Energy Management Software System for Small Commercial Buildings

Commercial buildings are responsible for approximately 20 percent of the total United States energy consumption and greenhouse gas emissions. Over 85 percent of these buildings lack building automation systems. Many of these buildings are small (<50,000 square feet), underserved, and use rooftop units for heating, ventilation, and air-conditioning needs. Because these buildings lack proper energy management systems, they have several operational deficiencies that lead to excess energy consumption. Studies have shown that managing the rooftop units heating and cooling set points, schedules, setbacks, and optimal start can result in 20 to 25 percent reduction in electricity consumption in small commercial buildings. In addition, improving demand flexibility of these buildings will result additional cost savings for the building owner. Therefore, the Department of Energy’s Building Technologies Office approved a project to address the needs for small commercial buildings. The project is led by Pacific Northwest National Laboratory (PNNL) with Intellimation LLC as the cooperative research and development agreement partner. The primary goal of the project is to develop and validate an autonomous energy management software (AEMS) system that will continuously optimize small commercial building operations by minimizing energy consumption and cost, while providing a solution for maximizing decarbonization benefits from electrification of buildings. The work will leverage the vast experience of PNNL research and development staff who have over two decades of experience in developing and successfully transferring software technologies to the private sector. This solution will be jointly developed with Intellimation, a company that plans to use it to scale their building energy efficiency (EE) and grid services offering. Widespread deployment of the AEMS system will improve the EE and demand flexibility of the building commercial building stock. It should also support cities and states in meeting their climate change mitigation goals. This document describes the various EE and grid service features of the AEMS system, infrastructure and data required to implement those features, and how the features should be automated. It also details how the various features will be tested and validated, including field validation. The document also details what flexibility the users have and how they will be able to leverage those capabilities exercise those. The intent is to create an AEMS system that would support scalable deployment, requires minimal configuration, and is easy to maintain over its expected lifespan. The initial alpha release of AEMS system is planned for March 2023, and the beta release is planned for the summer of 2023. The final release is planned for March 2024. Section 2 of the report documents the relevant building types that AEMS is suitable for. Section 3 documents EE features that will be supported. It will also include the data requirements, hardware requirements, implementation details, and how EE features will be tested and validated. Grid service features will be documented in section 4, including data requirements, hardware requirements, implementation details, and how the services will be tested and validated. Planned next steps are described in section 5.

32 ENERGY CONSERVATION, CONSUMPTION, AND UTILIZATI↗

The FORTRAN static source code analyzer program (SAP) user's guide, revision 1

The FORTRAN Static Source Code Analyzer Program (SAP) User's Guide (Revision 1) is presented. SAP is a software tool designed to assist Software Engineering Laboratory (SEL) personnel in conducting studies of FORTRAN programs. SAP scans FORTRAN source code and produces reports that present statistics and measures of statements and structures that make up a module. This document is a revision of the previous SAP user's guide, Computer Sciences Corporation document CSC/TM-78/6045. SAP Revision 1 is the result of program modifications to provide several new reports, additional complexity analysis, and recognition of all statements described in the FORTRAN 77 standard. This document provides instructions for operating SAP and contains information useful in interpreting SAP output.

Decker, W.↗

Computer Program Re-layers Engineering Drawings

RULCHK computer program aids in structuring layers of information pertaining to part or assembly designed with software described in article "Software for Drawing Design Details Concurrently" (MFS-28444). Checks and optionally updates structure of layers for part. Enables designer to construct model and annotate its documentation without burden of manually layering part to conform to standards at design time.

Crosby, Dewey C., III↗

MIDAS - Mission design and analysis software for the optimization of ballistic interplanetary trajectories

A patched conic trajectory optimization program MIDAS is described that was developed to investigate a wide variety of complex ballistic heliocentric transfer trajectories. MIDAS includes the capability of optimizing trajectory event times such as departure date, arrival date, and intermediate planetary flyby dates and is able to both add and delete deep space maneuvers when dictated by the optimization process. Both powered and unpowered flyby or gravity assist trajectories of intermediate bodies can be handled and capability is included to optimize trajectories having a rendezvous with an intermediate body such as for a sample return mission. Capability is included in the optimization process to constrain launch energy and launch vehicle parking orbit parameters.

Sauer, Carl G., Jr.↗

Analog/digital pH meter system I.C.

The project utilizes design automation software tools to design, simulate, and fabricate a pH meter integrated circuit (IC) system including a successive approximation type seven-bit analog to digital converter circuits using a 1.25 micron N-Well CMOS MOSIS process. The input voltage ranges from 0.5 to 1.0 V derived from a special type pH sensor, and the output is a three-digit decimal number display of pH with one decimal point.

Vincent, Paul↗