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.

SourceResearch connectionFrom yearThrough year

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

At least 199 records · Page 11

All sources NASA NTRS DOE OSTI

NASA NTRS2006

Automated Vectorization of Decision-Based Algorithms

Virtually all existing vectorization algorithms are designed to only analyze the numeric properties of an algorithm and distribute those elements across multiple processors. This advances the state of the practice because it is the only known system, at the time of this reporting, that takes high-level statements and analyzes them for their decision properties and converts them to a form that allows them to automatically be executed in parallel. The software takes a high-level source program that describes a complex decision- based condition and rewrites it as a disjunctive set of component Boolean relations that can then be executed in parallel. This is important because parallel architectures are becoming more commonplace in conventional systems and they have always been present in NASA flight systems. This technology allows one to take existing condition-based code and automatically vectorize it so it naturally decomposes across parallel architectures.

James, Mark↗

NASA NTRS2013

Adoption of Test Driven Development and Continuous Integration for the Development of the Trick Simulation Toolkit

This paper describes the adoption of a Test Driven Development approach and a Continuous Integration System in the development of the Trick Simulation Toolkit, a generic simulation development environment for creating high fidelity training and engineering simulations at the NASA/Johnson Space Center and many other NASA facilities. It describes what was learned and the significant benefits seen, such as fast, thorough, and clear test feedback every time code is checked-in to the code repository. It also describes a system that encourages development of code that is much more flexible, maintainable, and reliable. The Trick Simulation Toolkit development environment provides a common architecture for user-defined simulations. Trick builds executable simulations using user-supplied simulation-definition files (S_define) and user supplied "model code". For each Trick-based simulation, Trick automatically provides job scheduling, checkpoint / restore, data-recording, interactive variable manipulation (variable server), and an input-processor. Also included are tools for plotting recorded data and various other supporting tools and libraries. Trick is written in C/C++ and Java and supports both Linux and MacOSX. Prior to adopting this new development approach, Trick testing consisted primarily of running a few large simulations, with the hope that their complexity and scale would exercise most of Trick's code and expose any recently introduced bugs. Unsurprising, this approach yielded inconsistent results. It was obvious that a more systematic, thorough approach was required. After seeing examples of some Java-based projects that used the JUnit test framework, similar test frameworks for C and C++ were sought. Several were found, all clearly inspired by JUnit. Googletest, a freely available Open source testing framework, was selected as the most appropriate and capable. The new approach was implemented while rewriting the Trick memory management component, to eliminate a fundamental design flaw. The benefits became obvious almost immediately, not just in the correctness of the individual functions and classes but also in the correctness and flexibility being added to the overall design. Creating code to be testable, and testing as it was created resulted not only in better working code, but also in better-organized, flexible, and readable (i.e., articulate) code. This was, in essence the Test-driven development (TDD) methodology created by Kent Beck. Seeing the benefits of Test Driven Development, other Trick components were refactored to make them more testable and tests were designed and implemented for them.

Penn, John M.↗

NASA NTRS2015

Reconfigurable Very Long Instruction Word (VLIW) Processor

Future NASA missions will depend on radiation-hardened, power-efficient processing systems-on-a-chip (SOCs) that consist of a range of processor cores custom tailored for space applications. Aries Design Automation, LLC, has developed a processing SOC that is optimized for software-defined radio (SDR) uses. The innovation implements the Institute of Electrical and Electronics Engineers (IEEE) RazorII voltage management technique, a microarchitectural mechanism that allows processor cores to self-monitor, self-analyze, and selfheal after timing errors, regardless of their cause (e.g., radiation; chip aging; variations in the voltage, frequency, temperature, or manufacturing process). This highly automated SOC can also execute legacy PowerPC 750 binary code instruction set architecture (ISA), which is used in the flight-control computers of many previous NASA space missions. In developing this innovation, Aries Design Automation has made significant contributions to the fields of formal verification of complex pipelined microprocessors and Boolean satisfiability (SAT) and has developed highly efficient electronic design automation tools that hold promise for future developments.

Velev, Miroslav N.↗

NASA NTRS1987

The Massively Parallel Processor: Architecture and application

The massively parallel processor (MPP) has a simple, yet elegant architecture. Some have granted that it is novel, and other have claimed it to be fundamental. Whichever is the case, it has shown itself to be both useful and practical. Its hardware embodiment consumes relatively low power compared to other supercomputers, does not require special cooling, has an instruction cycle time that is relatively long, thus allowing it to avoid high speed technologies, and yet it competes respectably with any currently available supercomputer in speed of execution of applications. Due to the efficiency of the architecture, ease of construction and variety of applications, it is conceivable that within a few years computational accelerators more powerful than the MPP will be available at reasonable cost to be placed inside desktop workstations.

Dorband, John E.↗

NASA NTRS1998

The Tera Multithreaded Architecture and Unstructured Meshes

The Tera Multithreaded Architecture (MTA) is a new parallel supercomputer currently being installed at San Diego Supercomputing Center (SDSC). This machine has an architecture quite different from contemporary parallel machines. The computational processor is a custom design and the machine uses hardware to support very fine grained multithreading. The main memory is shared, hardware randomized and flat. These features make the machine highly suited to the execution of unstructured mesh problems, which are difficult to parallelize on other architectures. We report the results of a study carried out during July-August 1998 to evaluate the execution of EUL3D, a code that solves the Euler equations on an unstructured mesh, on the 2 processor Tera MTA at SDSC. Our investigation shows that parallelization of an unstructured code is extremely easy on the Tera. We were able to get an existing parallel code (designed for a shared memory machine), running on the Tera by changing only the compiler directives. Furthermore, a serial version of this code was compiled to run in parallel on the Tera by judicious use of directives to invoke the "full/empty" tag bits of the machine to obtain synchronization. This version achieves 212 and 406 Mflop/s on one and two processors respectively, and requires no attention to partitioning or placement of data issues that would be of paramount importance in other parallel architectures.

Bokhari, Shahid H.↗

NASA NTRS1990

Task directed sensing

High-level robot control research must confront the limitations imposed by real sensors if robots are to be controlled effectively in the real world. In particular, sensor limitations make it impossible to maintain a complete, detailed world model of the situation surrounding the robot. To address the problems involved in planning with the resulting incomplete and uncertain world models, traditional robot control architectures must be altered significantly. Task-directed sensing and control is suggested as a way of coping with world model limitations by focusing sensing and analysis resources on only those parts of the world relevant to the robot's active goals. The RAP adaptive execution system is used as an example of a control architecture designed to deploy sensing resources in this way to accomplish both action and knowledge goals.

Firby, R. James↗

NASA NTRS2014

The ISS 2B PVTCS Ammonia Leak: An Operational History

In 2006, the Photovoltaic Thermal Control System (PVTCS) for the International Space Station's 2B power channel began leaking ammonia at a rate of approximately 1.5lbm/year (out of a starting approximately 53lbm system ammonia mass). Initially, the operations strategy was "feed the leak," a strategy successfully put into action via Extra Vehicular Activity during the STS‐134 mission. During this mission the system was topped off with ammonia piped over from a separate thermal control system. This recharge was to have allowed for continued power channel operation into 2014 or 2015, at which point another EVA would have been required. Without these periodic EVAs to refill the 2B coolant system, the channel would eventually leak enough fluid as to risk pump cavitation and system failure, resulting in the loss of the 2B power channel - the most critical of the Space Station's 8 power channels. In mid‐2012, the leak rate increased to approximately 5lbm/year. Once discovered, an EVA was planned and executed within a 5 week timeframe to drastically alter the architecture of the PVTCS via connection to a dormant thermal control system not intended to be utilized as anything other than spare components. The purpose of this rerouting of the TCS was to increase system volume and to isolate the photovoltaic radiator, thought to be the likely leak source. This EVA was successfully executed on November 1st, 2012 and left the 2B PVTCS in a configuration where the system was now being adequately cooled via a totally different radiator than what the system was designed to utilize. Unfortunately, data monitoring over the next several months showed that the isolated radiator was not leaking, and the system itself continued to leak steadily until May 9th, 2013. It was on this day that the ISS crew noticed the visible presence of ammonia crystals escaping from the 2B channel's truss segment, signifying a rapid acceleration of the leak from 5lbm/year to 5lbm/day. Within 48 hours of the crew noticing the leak, an EVA was in progress to replace the coolant pump - the only other replaceable leak source. This paper will explore the management of the 2B PVTCS leak from the operations perspective. It will discuss the methodology of performing the STS‐134 refill, the considerations and contingency plans which went into the architectural overhaul of the system in 2012, and the unprecedented effort which went into the EVA response to the visible leak of May 2013. In particular the paper will focus on the techniques utilized by flight controllers to monitor the system health and to respond to such instances as the rapid May 2013 leak by putting the electrical system in a safe configuration for loss of cooling, and will use recorded telemetry of these events to describe system response to EVA crew and ground actions. It will discuss the innovative design for redundancy of the integrated truss structure's cooling systems which allowed for this leak to be managed with minimal impact to other ISS operations and electrical services, contrasted against the real unintended operations consequences of utilizing the flexibility of the spacecraft's design in this manner. The paper will discuss how the training of the crew and flight controller personnel has adapted to the changing architecture of the power system and the unpredictable nature of the 2B leak.

Vareha, Anthony↗

NASA NTRS1987

Strategies for concurrent processing of complex algorithms in data driven architectures

The results of ongoing research directed at developing a graph theoretical model for describing data and control flow associated with the execution of large grained algorithms in a spatial distributed computer environment is presented. This model is identified by the acronym ATAMM (Algorithm/Architecture Mapping Model). The purpose of such a model is to provide a basis for establishing rules for relating an algorithm to its execution in a multiprocessor environment. Specifications derived from the model lead directly to the description of a data flow architecture which is a consequence of the inherent behavior of the data and control flow described by the model. The purpose of the ATAMM based architecture is to optimize computational concurrency in the multiprocessor environment and to provide an analytical basis for performance evaluation. The ATAMM model and architecture specifications are demonstrated on a prototype system for concept validation.

Stoughton, John W.↗

NASA NTRSDate not supplied

Testing a Run-Time Assurance Framework Coupled with Integrated Risk Mitigation Capabilities for Autonomous Urban UAS Flights

The In-Time Aviation Safety Management System (IASMS) Concept of Operations (ConOps) envisions new capabilities to monitor, assess, and mitigate flight safety risks. Systems will be tailored to mission type, vehicle/equipage type, operational environment, and safety risk tolerance. Within an IASMS framework, several capabilities may be implemented spanning three operational phases (pre-flight, in-flight, and post-flight/off-line); and consisting of lower level functions and information services which may reside onboard the aircraft, on third-party server(s), and/or on ground/operator station(s). Each capability will be designed to produce and disseminate safety-relevant information; perform detection, diagnosis, and prediction of unsafe situations; and/or execute mitigation actions when hazardous events warrant such changes. This paper focuses on recent testing of airborne capabilities that demonstrate inflight aspects of the overarching concept for autonomous unmanned aircraft systems (UAS) operations in urban environments. A flight test architecture is described that applies run-time assurance principles (e.g., executes independent of the unassured autopilot), real-time risk assessment, and a technique to execute contingencies if necessary either automatically or via pilot intervention. Several tests using small UAS were conducted to verify the assured in-flight risk mitigation capability. The paper draws significantly from a larger NASA technical report and recent prior conference papers, providing additional details. Data is analyzed for two representative flights to illustrate the performance for various sequential and simultaneous hazards used during testing. During each automated flight, several hazards are encountered at various points along the flight path. At each point, the hazard is mitigated by the system, with the vehicle then continuing to subsequent points. The paper concludes with lessons-learned regarding relevant aspects of the overarching IASMS concept and how it may be updated and further advanced in the future.

population activity↗

NASA NTRS2016

On the Maneuvers Operational Response for NASA’s Soil Moisture Active-Passive (SMAP) Mission

The Soil-Moisture Active-Passive (SMAP) spacecraft requires various kinds of in-orbit maneuvers over the course of its three-year mission. The types of maneuvers include pre-planned commissioning maneuvers to reach its science orbit, regularly executed orbit maintenance maneuvers to overcome drag and other nominally occurring phenomena, as well as (the possibility of) collision avoidance maneuvers. The architecture of the spacecraft – in terms of availability of commanding via ground assets, the inherited avionics' ability to sequence and execute commands, and the capability of available subsystems able to carry out maneuvers – was well defined early in the development of the spacecraft and mission, well before the operational plan for responding to maneuver requests was cemented. The systems engineering challenge became: how to accommodate all three types of maneuvers in the confines of this well-defined architecture. This paper will describe how the operations team on SMAP successfully met this challenge. Specifically, it will dive into the three pronged approach that SMAP developed to handle each type of maneuver described above – to meet the timeliness requirements leveraged on the operations team to execute said maneuvers, while continuing to fit within the allotted staffing profile during nominal operations. Defining this paradigm to fit the mission’s architecture meant re-defining the original paradigm, (planned maneuvers being thought of separately than collision avoidance maneuvers), and re-classifying all responses to maneuver requests as variations and permutations of a singular operational response to a maneuver request. This paper will also describe the tools that were created to simplify the human interface and automate as much of the response as was possible. Finally, this paper will describe, at a very high level, some of the problems encountered and lessons learned by the operations team when this process was executed the first four times during the first ninety days of operations. Though the architecture of the operations team's response to maneuver requests will never be repeated exactly, the flexibility that was inserted via redefining the scope of the problem and by redefining the human interfaces should influence future projects' architectures earlier in their development – in the hopes that said influence will save time and money in the future.

Tirona, Joseph↗

NASA NTRS2004

The Robotic Lunar Exploration Program (RLEP): An Introduction to the Goals, Approach, and Architecture

The Vision for Space Exploration calls for undertaking lunar exploration activities to enable sustained human and robotic exploration of Mars and beyond, including more distant destinations in the solar system. In support of this vision, the Robotic Lunar Exploration Program (RLEP) is expected to execute a series of robotic missions to the Moon, starting in 2008, in order to pave the way for further human space exploration. This paper will give an introduction to the RLEP program office, its role and its goals, and the approach it is taking to executing the charter of the program. The paper will also discuss candidate architectures that are being studied as a framework for defining the RLEP missions and the context in which they will evolve.

Watzin, James G.↗

NASA NTRS2012

Virtual Machine Language 2.1

VML (Virtual Machine Language) is an advanced computing environment that allows spacecraft to operate using mechanisms ranging from simple, time-oriented sequencing to advanced, multicomponent reactive systems. VML has developed in four evolutionary stages. VML 0 is a core execution capability providing multi-threaded command execution, integer data types, and rudimentary branching. VML 1 added named parameterized procedures, extensive polymorphism, data typing, branching, looping issuance of commands using run-time parameters, and named global variables. VML 2 added for loops, data verification, telemetry reaction, and an open flight adaptation architecture. VML 2.1 contains major advances in control flow capabilities for executable state machines. On the resource requirements front, VML 2.1 features a reduced memory footprint in order to fit more capability into modestly sized flight processors, and endian-neutral data access for compatibility with Intel little-endian processors. Sequence packaging has been improved with object-oriented programming constructs and the use of implicit (rather than explicit) time tags on statements. Sequence event detection has been significantly enhanced with multi-variable waiting, which allows a sequence to detect and react to conditions defined by complex expressions with multiple global variables. This multi-variable waiting serves as the basis for implementing parallel rule checking, which in turn, makes possible executable state machines. The new state machine feature in VML 2.1 allows the creation of sophisticated autonomous reactive systems without the need to develop expensive flight software. Users specify named states and transitions, along with the truth conditions required, before taking transitions. Transitions with the same signal name allow separate state machines to coordinate actions: the conditions distributed across all state machines necessary to arm a particular signal are evaluated, and once found true, that signal is raised. The selected signal then causes all identically named transitions in all present state machines to be taken simultaneously. VML 2.1 has relevance to all potential space missions, both manned and unmanned. It was under consideration for use on Orion.

Riedel, Joseph E.↗

NASA NTRS1997

A Multi-Level Parallelization Concept for High-Fidelity Multi-Block Solvers

The integration of high-fidelity Computational Fluid Dynamics (CFD) analysis tools with the industrial design process benefits greatly from the robust implementations that are transportable across a wide range of computer architectures. In the present work, a hybrid domain-decomposition and parallelization concept was developed and implemented into the widely-used NASA multi-block Computational Fluid Dynamics (CFD) packages implemented in ENSAERO and OVERFLOW. The new parallel solver concept, PENS (Parallel Euler Navier-Stokes Solver), employs both fine and coarse granularity in data partitioning as well as data coalescing to obtain the desired load-balance characteristics on the available computer platforms. This multi-level parallelism implementation itself introduces no changes to the numerical results, hence the original fidelity of the packages are identically preserved. The present implementation uses the Message Passing Interface (MPI) library for interprocessor message passing and memory accessing. By choosing an appropriate combination of the available partitioning and coalescing capabilities only during the execution stage, the PENS solver becomes adaptable to different computer architectures from shared-memory to distributed-memory platforms with varying degrees of parallelism. The PENS implementation on the IBM SP2 distributed memory environment at the NASA Ames Research Center obtains 85 percent scalable parallel performance using fine-grain partitioning of single-block CFD domains using up to 128 wide computational nodes. Multi-block CFD simulations of complete aircraft simulations achieve 75 percent perfect load-balanced executions using data coalescing and the two levels of parallelism. SGI PowerChallenge, SGI Origin 2000, and a cluster of workstations are the other platforms where the robustness of the implementation is tested. The performance behavior on the other computer platforms with a variety of realistic problems will be included as this on-going study progresses.

Hatay, Ferhat F.↗

NASA NTRS1989

Space applications of artificial intelligence; Proceedings of the Annual Goddard Conference, Greenbelt, MD, May 16, 17, 1989

Theoretical and implementation aspects of AI systems for space applications are discussed in reviews and reports. Sections are devoted to planning and scheduling, fault isolation and diagnosis, data management, modeling and simulation, and development tools and methods. Particular attention is given to a situated reasoning architecture for space repair and replace tasks, parallel plan execution with self-processing networks, the electrical diagnostics expert system for Spacelab life-sciences experiments, diagnostic tolerance for missing sensor data, the integration of perception and reasoning in fast neural modules, a connectionist model for dynamic control, and applications of fuzzy sets to the development of rule-based expert systems.

Rash, James L.↗

NASA NTRS2001

General Temporal Knowledge for Planning and Data Mining

We consider the architecture of systems that combine temporal planning and plan execution and introduce a layer of temporal reasoning that potential1y improves both the communication between humans and such systems, and the performance of the temporal planner itself. In particular, this additional layer simultaneously supports more flexibility in specifying and maintaining temporal constraints on plans within an uncertain and changing execution environment, and the ability to understand and trace the progress of plan execution. It is shown how a representation based on single set of abstractions of temporal information can be used to characterize the reasoning underlying plan generation and execution interpretation. The complexity of such reasoning is discussed.

Morris, Robert↗

NASA NTRS2005

NASA Capability Roadmaps Executive Summary

This document is the result of eight months of hard work and dedication from NASA, industry, other government agencies, and academic experts from across the nation. It provides a summary of the capabilities necessary to execute the Vision for Space Exploration and the key architecture decisions that drive the direction for those capabilities. This report is being provided to the Exploration Systems Architecture Study (ESAS) team for consideration in development of an architecture approach and investment strategy to support NASA future mission, programs and budget requests. In addition, it will be an excellent reference for NASA's strategic planning. A more detailed set of roadmaps at the technology and sub-capability levels are available on CD. These detailed products include key driving assumptions, capability maturation assessments, and technology and capability development roadmaps.

Willcoxon, Rita↗

NASA NTRS2010

A High-Fidelity Simulation of a Generic Commercial Aircraft Engine and Controller

A new high-fidelity simulation of a generic 40,000 lb thrust class commercial turbofan engine with a representative controller, known as CMAPSS40k, has been developed. Based on dynamic flight test data of a highly instrumented engine and previous engine simulations developed at NASA Glenn Research Center, this non-proprietary simulation was created especially for use in the development of new engine control strategies. C-MAPSS40k is a highly detailed, component-level engine model written in MATLAB/Simulink (The MathWorks, Inc.). Because the model is built in Simulink, users have the ability to use any of the MATLAB tools for analysis and control system design. The engine components are modeled in C-code, which is then compiled to allow faster-than-real-time execution. The engine controller is based on common industry architecture and techniques to produce realistic closed-loop transient responses while ensuring that no safety or operability limits are violated. A significant feature not found in other non-proprietary models is the inclusion of transient stall margin debits. These debits provide an accurate accounting of the compressor surge margin, which is critical in the design of an engine controller. This paper discusses the development, characteristics, and capabilities of the C-MAPSS40k simulation

May, Ryan D.↗

NASA NTRS2016

Future Standardization of Space Telecommunications Radio System with Core Flight System

NASA Glenn Research Center (GRC) is integrating the NASA Space Telecommunications Radio System (STRS) Standard with the Core Flight System (cFS). The STRS standard provides a common, consistent framework to develop, qualify, operate and maintain complex, reconfigurable and reprogrammable radio systems. The cFS is a flexible, open architecture that features a plug-and-play software executive called the Core Flight Executive (cFE), a reusable library of software components for flight and space missions and an integrated tool suite. Together, STRS and cFS create a development environment that allows for STRS compliant applications to reference the STRS APIs through the cFS infrastructure. These APis are used to standardize the communication protocols on NASAs space SDRs. The cFE-STRS Operating Environment (OE) is a portable cFS library, which adds the ability to run STRS applications on existing cFS platforms. The purpose of this paper is to discuss the cFE-STRS OE prototype, preliminary experimental results performed using the Advanced Space Radio Platform (ASRP), the GRC Sband Ground Station and the SCaN (Space Communication and Navigation) Testbed currently flying onboard the International Space Station. Additionally, this paper presents a demonstration of the Consultative Committee for Space Data Systems (CCSDS) Spacecraft Onboard Interface Services (SOIS) using electronic data sheets inside cFE. This configuration allows for the data sheets to specify binary formats for data exchange between STRS applications. The integration of STRS with cFS leverages mission-proven platform functions and mitigates barriers to integration with future missions. This reduces flight software development time and the costs of software-defined radio (SDR) platforms. Furthermore, the combined benefits of STRS standardization with the flexibility of cFS provide an effective, reliable and modular framework to minimize software development efforts for spaceflight missions.

space communications↗