Engineering Papers⌕ Search

SEARCH · Engineering Papers

Results for “execution architecture”

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 505 records · Page 28
All sourcesNASA NTRSDOE OSTI
NASA NTRS2003

Design for Verification: Using Design Patterns to Build Reliable Systems

Components so far have been mainly used in commercial software development to reduce time to market. While some effort has been spent on formal aspects of components, most of this was done in the context of programming language or operating system framework integration. As a consequence, increased reliability of composed systems is mainly regarded as a side effect of a more rigid testing of pre-fabricated components. In contrast to this, Design for Verification (D4V) puts the focus on component specific property guarantees, which are used to design systems with high reliability requirements. D4V components are domain specific design pattern instances with well-defined property guarantees and usage rules, which are suitable for automatic verification. The guaranteed properties are explicitly used to select components according to key system requirements. The D4V hypothesis is that the same general architecture and design principles leading to good modularity, extensibility and complexity/functionality ratio can be adapted to overcome some of the limitations of conventional reliability assurance measures, such as too large a state space or too many execution paths.

Mehlitz, Peter C.↗
NASA NTRS2006

A Discussion of the Discrete Fourier Transform Execution on a Typical Desktop PC

This paper will discuss and compare the execution times of three examples of the Discrete Fourier Transform (DFT). The first two examples will demonstrate the direct implementation of the algorithm. In the first example, the Fourier coefficients are generated at the execution of the DFT. In the second example, the coefficients are generated prior to execution and the DFT coefficients are indexed at execution. The last example will demonstrate the Cooley- Tukey algorithm, better known as the Fast Fourier Transform. All examples were written in C executed on a PC using a Pentium 4 running at 1.7 Ghz. As a function of N, the total complex data size, the direct implementation DFT executes, as expected at order of N2 and the FFT executes at order of N log2 N. At N=16K, there is an increase in processing time beyond what is expected. This is not caused by implementation but is a consequence of the effect that machine architecture and memory hierarchy has on implementation. This paper will include a brief overview of digital signal processing, along with a discussion of contemporary work with discrete Fourier processing.

White, Michael J.↗
NASA NTRS2004

Preliminary results of the autonomous sciencecraft experiment

The Autonomous Sciencecraft Experiment (ASE) will operate onboard the Earth Orbiter 1 mission in 2003. The ASE software uses onboard continuous planning, robust task and goal-based execution, and onboard machine learning and pattern recognition to radically increase science return by enabling intelligent downlink selection and autonomous retargeting. In this paper we discuss how these AI technologies are synergistically integrated in multilayer control architecture to enable a virtual spacecraft science agent.

Rabideau, Gregg↗
NASA NTRS1996

Development of a Computer Architecture to Support the Optical Plume Anomaly Detection (OPAD) System

The NASA OPAD spectrometer system relies heavily on extensive software which repetitively extracts spectral information from the engine plume and reports the amounts of metals which are present in the plume. The development of this software is at a sufficiently advanced stage where it can be used in actual engine tests to provide valuable data on engine operation and health. This activity will continue and, in addition, the OPAD system is planned to be used in flight aboard space vehicles. The two implementations, test-stand and in-flight, may have some differing requirements. For example, the data stored during a test-stand experiment are much more extensive than in the in-flight case. In both cases though, the majority of the requirements are similar. New data from the spectrograph is generated at a rate of once every 0.5 sec or faster. All processing must be completed within this period of time to maintain real-time performance. Every 0.5 sec, the OPAD system must report the amounts of specific metals within the engine plume, given the spectral data. At present, the software in the OPAD system performs this function by solving the inverse problem. It uses powerful physics-based computational models (the SPECTRA code), which receive amounts of metals as inputs to produce the spectral data that would have been observed, had the same metal amounts been present in the engine plume. During the experiment, for every spectrum that is observed, an initial approximation is performed using neural networks to establish an initial metal composition which approximates as accurately as possible the real one. Then, using optimization techniques, the SPECTRA code is repetitively used to produce a fit to the data, by adjusting the metal input amounts until the produced spectrum matches the observed one to within a given level of tolerance. This iterative solution to the original problem of determining the metal composition in the plume requires a relatively long period of time to execute the software in a modern single-processor workstation, and therefore real-time operation is currently not possible. A different number of iterations may be required to perform spectral data fitting per spectral sample. Yet, the OPAD system must be designed to maintain real-time performance in all cases. Although faster single-processor workstations are available for execution of the fitting and SPECTRA software, this option is unattractive due to the excessive cost associated with very fast workstations and also due to the fact that such hardware is not easily expandable to accommodate future versions of the software which may require more processing power. Initial research has already demonstrated that the OPAD software can take advantage of a parallel computer architecture to achieve the necessary speedup. Current work has improved the software by converting it into a form which is easily parallelizable. Timing experiments have been performed to establish the computational complexity and execution speed of major components of the software. This work provides the foundation of future work which will create a fully parallel version of the software executing in a shared-memory multiprocessor system.

Katsinis, Constantine↗
NASA NTRS2018

The OpenSE Cookbook: A Practical, Recipe Based Collection of Patterns, Procedures, and Best Practices for Executable Systems Engineering for the Thirty Meter Telescope

The OpenSE Cookbook is an open-sourced collection of patterns, procedures, and best practices targeted for systems engineers who seek guidance on applying model-based and executable systems engineering (MBSE) using SysML. Its content has emerged from the system level modeling effort on the European Framework Program 6 (FP6) and the Thirty Meter Telescope (TMT). The TMT MBSE approach applied the Executable Systems Engineering Method (ESEM) and the open-source Engineering Environment (OpenMBEE) to specify, analyze, and verify requirements of TMT’s Alignment and Phasing System (APS) and the Narrow Field Infrared Adaptive Optics System (NFIRAOS). In these applications, implicit dependencies are made explicit in a formal model through the use of ESEM, OpenMBEE, and SysML modeling constructs. The value proposition for applying this MBSE approach was to establish precise requirements and fine-grained traceability to system designs, and to verify key requirements beginning early in development. The integration of ESEM and the OpenMBEE tooling infrastructure (providing linked-data and web-operability) is a significant added value for the MBSE approach. The APS is responsible for the overall pre-adaptive optics wavefront quality, using starlight to measure wavefront errors and align the TMT optics. In the formally integrated and executable SysML model, simulations are performed to analyze the impact of changed requirements and verify specified constraints for various operational scenarios. The APS team used several modeling patterns to capture information such as the requirements, the operational scenarios, involved subsystems and their interaction points, the estimated or required time durations, and the mass and power consumption. Adaptive optics systems are designed to sense real-time atmospheric turbulence and correct the telescope’s optical beam to remove its effect. The system model for the adaptive optics operational modes was developed to capture sequence behaviors and operational scenarios to run Monte-Carlo simulations for verifying acquisition time, observing efficiency, and operational behavior requirements. The model is particularly useful for investigating the effect of parallelization, identifying interface issues, and re-ordering sequence acquisition tasks. A former version of the Cookbook (which is now updated to MBSE challenges, goals, and lessons learned) included modeling guidelines and conventions for all system aspects, hierarchy levels, and views, which were developed during for the Active Phasing Experiment (APE), an opto-mechatronical system technology demonstrator for the Extremely Large Telescope (ELT). The Cookbook utilizes the above mentioned system models as real-world case-studies to demonstrate and document the applications of the recipes, providing also instructional examples and addressing the available tooling support. The Cookbook is accompanied by a number of SysML models and aodel libraries which facilitate model authoring and maintenance. The Cookbook covers the different aspects of Systems Engineering such as management of Requirements, Design (behavior and structure), Interfaces, Interdisciplinary Integration, Analysis, Trade Studies, and Technical Resources. This paper presents the background, motivation, architecture, and highlights some key content of the Cookbook. For example, interface management, error budget management, requirements verification, Monte Carlo driven analysis, and timing analysis of operational scenarios. The paper discusses how the capabilities of OpenMBEE contributed significantly to the adoption of executable systems engineering.

Brower, Eric↗
NASA NTRS2004

The Role of Ontologies in Schema-based Program Synthesis

Program synthesis is the process of automatically deriving executable code from (non-executable) high-level specifications. It is more flexible and powerful than conventional code generation techniques that simply translate algorithmic specifications into lower-level code or only create code skeletons from structural specifications (such as UML class diagrams). Key to building a successful synthesis system is specializing to an appropriate application domain. The AUTOBAYES and AUTOFILTER systems, under development at NASA Ames, operate in the two domains of data analysis and state estimation, respectively. The central concept of both systems is the schema, a representation of reusable computational knowledge. This can take various forms, including high-level algorithm templates, code optimizations, datatype refinements, or architectural information. A schema also contains applicability conditions that are used to determine when it can be applied safely. These conditions can refer to the initial specification, to intermediate results, or to elements of the partially-instantiated code. Schema-based synthesis uses AI technology to recursively apply schemas to gradually refine a specification into executable code. This process proceeds in two main phases. A front-end gradually transforms the problem specification into a program represented in an abstract intermediate code. A backend then compiles this further down into a concrete target programming language of choice. A core engine applies schemas on the initial problem specification, then uses the output of those schemas as the input for other schemas, until the full implementation is generated. Since there might be different schemas that implement different solutions to the same problem this process can generate an entire solution tree. AUTOBAYES and AUTOFILTER have reached the level of maturity where they enable users to solve interesting application problems, e.g., the analysis of Hubble Space Telescope images. They are large (in total around 100kLoC Prolog), knowledge intensive systems that employ complex symbolic reasoning to generate a wide range of non-trivial programs for complex application do- mains. Their schemas can have complex interactions, which make it hard to change them in isolation or even understand what an existing schema actually does. Adding more capabilities by increasing the number of schemas will only worsen this situation, ultimately leading to the entropy death of the synthesis system. The root came of this problem is that the domain knowledge is scattered throughout the entire system and only represented implicitly in the schema implementations. In our current work, we are addressing this problem by making explicit the knowledge from Merent parts of the synthesis system. Here; we discuss how Gruber's definition of an ontology as an explicit specification of a conceptualization matches our efforts in identifying and explicating the domain-specific concepts. We outline the dual role ontologies play in schema-based synthesis and argue that they address different audiences and serve different purposes. Their first role is descriptive: they serve as explicit documentation, and help to understand the internal structure of the system. Their second role is prescriptive: they provide the formal basis against which the other parts of the system (e.g., schemas) can be checked. Their final role is referential: ontologies also provide semantically meaningful "hooks" which allow schemas and tools to access the internal state of the program derivation process (e.g., fragments of the generated code) in domain-specific rather than language-specific terms, and thus to modify it in a controlled fashion. For discussion purposes we use AUTOLINEAR, a small synthesis system we are currently experimenting with, which can generate code for solving a system of linear equations, Az = b.

Bures, Tomas↗
NASA NTRS2013

Scheduling Operations for Massive Heterogeneous Clusters

High-performance computing (HPC) programming has become increasingly difficult with the advent of hybrid supercomputers consisting of multicore CPUs and accelerator boards such as the GPU. Manual tuning of software to achieve high performance on this type of machine has been performed by programmers. This is needlessly difficult and prone to being invalidated by new hardware, new software, or changes in the underlying code. A system was developed for task-based representation of programs, which when coupled with a scheduler and runtime system, allows for many benefits, including higher performance and utilization of computational resources, easier programming and porting, and adaptations of code during runtime. The system consists of a method of representing computer algorithms as a series of data-dependent tasks. The series forms a graph, which can be scheduled for execution on many nodes of a supercomputer efficiently by a computer algorithm. The schedule is executed by a dispatch component, which is tailored to understand all of the hardware types that may be available within the system. The scheduler is informed by a cluster mapping tool, which generates a topology of available resources and their strengths and communication costs. Software is decoupled from its hardware, which aids in porting to future architectures. A computer algorithm schedules all operations, which for systems of high complexity (i.e., most NASA codes), cannot be performed optimally by a human. The system aids in reducing repetitive code, such as communication code, and aids in the reduction of redundant code across projects. It adds new features to code automatically, such as recovering from a lost node or the ability to modify the code while running. In this project, the innovators at the time of this reporting intend to develop two distinct technologies that build upon each other and both of which serve as building blocks for more efficient HPC usage. First is the scheduling and dynamic execution framework, and the second is scalable linear algebra libraries that are built directly on the former.

Humphrey, John↗
NASA NTRS2001

Summary of ADTT Website Functionality and Features

This report summarizes development of the ADTT web-based design environment by the ELORET team in 2000. The Advanced Design Technology Testbed had been in development for several years, with demonstration applications restricted to aerodynamic analyses of subsonic aircraft. The key changes achieved this year were improvements in Web-based accessibility, evaluation of collaborative visualization, remote invocation of geometry updates and performance analysis, and application to aerospace system analysis. Significant effort was also devoted to post-processing of data, chiefly through comparison of similar data for alternative vehicle concepts. Such comparison is an essential requirement for designers to make informed choices between alternatives. The next section of this report provides more discussion of the goals for ADTT development. Section 3 provides screen shots from a sample session in the ADTT environment, including Login and navigation to the project of interest, data inspection, analysis execution and output evaluation. The following section provides discussion of implementation details and recommendations for future development of the software and information technologies that provide the key functionality of the ADTT system. Section 5 discusses the integration architecture for the system, which links machines running different operating systems and provides unified access to data stored in distributed locations. Security is a significant issue for this system, especially for remote access to NAS machines, so Section 6 discusses several architectural considerations with respect to security. Additional details of some aspects of ADTT development are included in Appendices.

Hawke, Veronica↗
NASA NTRS2006

Architecture for Control of the K9 Rover

Software featuring a multilevel architecture is used to control the hardware on the K9 Rover, which is a mobile robot used in research on robots for scientific exploration and autonomous operation in general. The software consists of five types of modules: Device Drivers - These modules, at the lowest level of the architecture, directly control motors, cameras, data buses, and other hardware devices. Resource Managers - Each of these modules controls several device drivers. Resource managers can be commanded by either a remote operator or the pilot or conditional-executive modules described below. Behaviors and Data Processors - These modules perform computations for such functions as planning paths, avoiding obstacles, visual tracking, and stereoscopy. These modules can be commanded only by the pilot. Pilot - The pilot receives a possibly complex command from the remote operator or the conditional executive, then decomposes the command into (1) more-specific commands to the resource managers and (2) requests for information from the behaviors and data processors. Conditional Executive - This highest-level module interprets a command plan sent by the remote operator, determines whether resources required for execution of the plan are available, monitors execution, and, if necessary, selects an alternate branch of the plan.

Bresina, John L.↗
NASA NTRS2016

Design and Execution of Dawn HAMO to LAMO Transfer at Ceres

On October 23, 2015, the Dawn spacecraft left the High Altitude Mapping Orbit (HAMO) around Ceres and began its final decent to the Low Altitude Mapping Orbit (LAMO), arriving on December 15. The transfer between the two science orbits, a tight spiraling trajectory with over 100 revolutions, required the operations team to perform weekly maneuver designs for a period of 50 days. While the first six weeks of the transfer executed as planned, unexpectedly the spacecraft incurred a multi-sigma delivery error to the final science orbit that was subsequently clean-up at the first orbit maintenance maneuver. In this paper we discuss the design architecture for the transfer in detail, including challenges the team faced in flying the transfer and lessons learned.

Grebow, Daniel J.↗
NASA NTRS2016

Design and Execution of Dawn HAMO to LAMO Transfer at Ceres

On October 23, 2015, the Dawn spacecraft left the High Altitude Mapping Orbit (HAMO) around Ceres and began its final decent to the Low Altitude Mapping Orbit (LAMO), arriving on December 15. The transfer between the two science orbits, a tight spiraling trajectory with over 100 revolutions, required the operations team to perform weekly maneuver designs for a period of 50 days. While the first six weeks of the transfer executed as planned, unexpectedly the spacecraft incurred a multi-sigma delivery error to the final science orbit that was subsequently clean-up at the first orbit maintenance maneuver. In this paper we discuss the design architecture for the transfer in detail, including challenges the team faced in flying the transfer and lessons learned.

Grebow, Dan↗
NASA NTRSDate not supplied

NASA Gateway Refueling Architecture and Concept of Operation

The Lunar Gateway is a deep space orbiting outpost being developed by NASA in partnership with ESA and other domestic and international partners. It is a critical component of NASA’s Artemis program supporting long-term human exploration of the moon and is designed to be refueled, requiring the on-orbit transfer of propellants. The first two modules of Gateway to be launched will be the Power and Propulsion Element (PPE) and the Habitation and Logistics Outpost (HALO). The PPE contains the bipropellant chemical and electrical propulsion systems that will provide attitude control and orbit raising capability for Gateway. The reaction control system (RCS) utilizes monomethylhydrazine (MMH) and mixed oxides of nitrogen-3 (MON-3) as the fuel and oxidizer, respectively. Helium is used as a pressurant. The Advanced Electric Propulsion Systems (AEPS) and Busek hall thrusters that comprise the solar electric propulsion (SEP) system use xenon as the propellent. The ESPRIT Refueling Module, provided by ESA, will supply the propellant refueling function to Gateway’s propulsion systems. On-orbit refueling is a complex, technically challenging operation that is key to enabling sustainable crewed Lunar and Martian exploration. Numerous systems may be involved in the refueling operation. Also numerous systems are required to enable the successful ability for Gateway to refuel such as, SEP, RCS, Structure & Mechanisms (S&M), Guidance, Navigation and Control (GNC), Thermal, Software, Vehicle System Manager (VSM), Flight Ops, Extra Vehicular Robotics (EVR), Communication and Tracking (C&T), Avionics, and more. This paper will detail the design architecture, concept of operations, and challenges associated with the Gateway refueling system. The methodologies used in Gateway will be compared to those implemented in OSAM-1 and the best practices documented by AIAA and CONFERS (Consortium For Execution Of Rendezvous And Servicing Operations).

Brandie L. Rhodes↗
NASA NTRS2001

Autonomy technology at JPL

This paper and exhibit describes the on-going research activities, plans and products of the Autonomy Technology program at NASA Jet Propulsion Laboratory. In this paper, we briefly describe the areas of Mission Planning and Execution, Distributed Autonomous Systems, Science Data Understanding, and Autonomous Guidance and Control.

autonomous rovers distributed systems planning con↗
NASA NTRS1984

FORTH direct execution processors in the Hopkins ultraviolet telescope

Engineers at the Johns Hopkins University Applied Physics Laboratory have designed and built two computers which will control and monitor the Hopkins Ultraviolet Telescope, a 1986 Space Shuttle experiment. These computers implement a microcoded FORTH nucleus in a word-addressed AMD 2900 series bit-slice architecture. All programs for them are written in FORTH, which takes the place of assembly language in this architecture.

Ballard, Ben↗
NASA NTRS1984

PASLIB programmer's guide for the finite element machine, revision 2.1-A

PASLIB is a library of Pascal callable subroutines designed to give application programs access to the unique architectural features of the Finite Element Machine and to the software support services provided by the Nodal Exec operating system which runs on it. The PASLIB subroutines are documented and the procedures needed to write Pascal programs for execution on the Finite Element Machine are defined. Considerations for obtaining optimum hardware and software performance are given. A brief overview of debugging and performance analysis capabilities available to the programmer is presented.

Crockett, T. W.↗
NASA NTRS1990

Rapid recovery from transient faults in the fault-tolerant processor with fault-tolerant shared memory

The Draper fault-tolerant processor with fault-tolerant shared memory (FTP/FTSM), which is designed to allow application tasks to continue execution during the memory alignment process, is described. Processor performance is not affected by memory alignment. In addition, the FTP/FTSM incorporates a hardware scrubber device to perform the memory alignment quickly during unused memory access cycles. The FTP/FTSM architecture is described, followed by an estimate of the time required for channel reintegration.

Harper, Richard E.↗
NASA NTRS2005

Current results from a Rover Science Data Analysis System

In this paper, we provide a brief overview of the OASIS system, and then describe our recent successes in integrating with and using rover hardware. OASIS currently works in a closed loop fashion with onboard control software (e.g., navigation and vision) and has the ability to autonomously perform the following sequence of steps: analyze gray scale images to find rocks, extract the properties of the rocks, identify rocks of interest, retask the rover to take additional imagery of the identified target and then allow the rover to continue on its original mission. We also describe the early 2004 ground test validation of specific OASIS components on selected Mars Exploration Rover (MER) images. These components include the rockfinding algorithm, RockIT, and the rock size feature extraction code. Our team also developed the RockIT GUI, an interface that allows users to easily visualize and modify the rock-finder results. This interface has allowed us to conduct preliminary testing and validation of the rockfinder's performance.

Coupled Layer Architecture for Robotic Autonomy (C↗
NASA NTRS2007

Micromechanics of Spray-On Foam Insulation

Understanding the thermo-mechanical response of the Space Shuttle External Tank spray-on foam insulation (SOFI) material is critical, to NASA's Return to Flight effort. This closed-cell rigid polymeric foam is used to insulate the metallic Space Shuttle External Tank, which is at cryogenic temperatures immediately prior to and during lift off. The shedding of the SOFI during ascent led to the loss of the Columbia, and eliminating/minimizing foam lass from the tank has become a priority for NASA as it seeks to resume scheduled space shuttle missions. Determining the nature of the SOFI material behavior in response to both thermal and mechanical loading plays an important role as any structural modeling of the shedding phenomenon k predicated on knowledge of the constitutive behavior of the foam. In this paper, the SOFI material has been analyzed using the High-Fidelity Generalized Method of Cells (HFGMC) micromechanics model, which has recently been extended to admit a triply-periodic 3-D repeating unit cell (RUC). Additional theoretical extensions that mere made in order to enable modeling of the closed-cell-foam material include the ability to represent internal boundaries within the RUC (to simulated internal pores) and the ability to impose an internal pressure within the simulated pores. This latter extension is crucial as two sources contribute to significant internal pressure changes within the SOFI pores. First, gas trapped in the pores during the spray process will expand or contract due to temperature changes. Second, the pore pressure will increase due to outgassing of water and other species present in the foam skeleton polymer material. With HFGMC's new pore pressure modeling capabilities, a nonlinear pressure change within the simulated pore can be imposed that accounts for both of these sources, in addition to stmdar&-thermal and mechanical loading; The triply-periodic HFGMC micromechanics model described above was implemented within NASA GRC's MAC/GMC software package, giving the model access to a range of nonlinear constitutive models for the polymeric foam skeleton material. A repeating unit cell architecture was constructed that, while relatively simple, still accounts for the geometric anisotropy of the porous foam microstructure and its thin walls and thicker edges. With the lack of reliable polymeric foam skeleton materia1 properties, many simulations were executed aimed at backing out these material properties. Then, using these properties, predictions of the thermo-mechanical behavior of the foam, including calculated internal applied pressure profiles, were performed and compared with appropriate experimental data.

Bednarcyk, Brett A.↗