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 235 records · Page 13

Maintaining Situation Awareness with Autonomous Airborne Observation Platforms

Unmanned Aerial Vehicles (UAVs) offer tremendous potential as intelligence, surveillance and reconnaissance (ISR) platforms for early detection of security threats and for acquisition and maintenance of situation awareness in crisis conditions. However, using their capabilities effectively requires addressing a range of practical and theoretical problems. The paper will describe progress by the "Autonomous Rotorcraft Project," a collaborative effort between NASA and the U.S. Army to develop a practical, flexible capability for UAV-based ISR. Important facets of the project include optimization methods for allocating scarce aircraft resources to observe numerous, distinct sites of interest; intelligent flight automation software than integrates high-level plan generation capabilities with executive control, failure response and flight control functions; a system architecture supporting reconfiguration of onboard sensors to address different kinds of threats; and an advanced prototype vehicle designed to allow large-scale production at low cost. The paper will also address human interaction issues including an empirical method for determining how to allocate roles and responsibilities between flight automation and human operations.

Freed, Michael↗

Coordinated Science Campaign Scheduling for Sensor Webs

Future Earth observing missions will study different aspects and interacting pieces of the Earth's eco-system. Scientists are designing increasingly complex, interdisciplinary campaigns to exploit the diverse capabilities of multiple Earth sensing assets. In addition, spacecraft platforms are being configured into clusters, trains, or other distributed organizations in order to improve either the quality or the coverage of observations. These simultaneous advances in the design of science campaigns and in the missions that will provide the sensing resources to support them offer new challenges in the coordination of data and operations that are not addressed by current practice. For example, the scheduling of scientific observations for satellites in low Earth orbit is currently conducted independently by each mission operations center. An absence of an information infrastructure to enable the scheduling of coordinated observations involving multiple sensors makes it difficult to execute campaigns involving multiple assets. This paper proposes a software architecture and describes a prototype system called DESOPS (Distributed Earth Science Observation Planning and Scheduling) that will address this deficiency.

Edgington, Will↗

Crew Transportation System Design Reference Missions

Contains summaries of potential design reference mission goals for systems to transport humans to andfrom low Earth orbit (LEO) for the Commercial Crew Program. The purpose of this document is to describe Design Reference Missions (DRMs) representative of the end-to-end Crew Transportation System (CTS) framework envisioned to successfully execute commercial crew transportation to orbital destinations. The initial CTS architecture will likely be optimized to support NASA crew and NASA-sponsored crew rotation missions to the ISS, but consideration may be given in this design phase to allow for modifications in order to accomplish other commercial missions in the future. With the exception of NASA’s mission to the ISS, the remaining commercial DRMs are notional. Any decision to design or scar the CTS for these additional non-NASA missions is completely up to the Commercial Provider. As NASA’s mission needs evolve over time, this document will be periodically updated to reflect those needs.

potential design reference↗

Development of the Artemis Distributed Simulation FOMs

The National Aeronautics and Space Administration (NASA) is formulating and developing the Artemis Program, a collaboration with domestic commercial and international partners that will establish a long term human presence on the Moon and extend human exploration beyond the Earth-Moon system ahead of exploring Mars. These Artemis partners are developing a portfolio of space and surface systems to support human missions to the lunar surface and beyond. The Artemis systems will provide the mobility, habitation, and logistics infrastructure that will support human exploration and foster robust scientific investigations. Each partner will contribute one or more elements to the Artemis Program with NASA having the overarching responsibility for defining the Artemis architecture and guiding the integration of this complex system of space systems. To successfully accomplish this audacious task, NASA will rely on the development and execution of many complex models and simulations. Many of these simulations will be provided by the Artemis partners. While each of these simulations will provide important insight into the characteristics and performance of an associated system, individually they will not provide insight into the integrated performance of the architecture and the system of systems working in concert to execute a given Artemis mission. To address this need, NASA is developing a distributed simulation capability called the Artemis Distributed Simulation (ADS). ADS’s distributed nature supports the complex aggregation of constituent Artemis element simulations. Artemis partner simulations will be able to join into an ADS-based distributed simulation and interact with other Artemis element simulations while limiting the exposure of proprietary designs and data. ADS is defining a distributed simulation capability built on international simulation interoperability standards, specifically the High Level Architecture (HLA) and the Space Reference Federation Object Model (SpaceFOM). While HLA and SpaceFOM provide the substantive necessary technology basis for ADS, additional common datatypes, message definitions, and execution protocols are required. These extensions constitute the ADS Federation Object Model (FOM). This paper describes the fundamental architectural elements of ADS and the FOM extensions needed to support the complex nature of the Artemis Program. This includes the examination of the ADS FOM modules, ADS base datatypes, ADS SpaceFOM Object Class extensions, new ADS Object Classes, and new ADS Interaction Classes.

HLA↗

Development of the Artemis Distributed Simulation FOMs

The National Aeronautics and Space Administration (NASA) is formulating and developing the Artemis Program, a collaboration with domestic commercial and international partners that will establish a long term human presence on the Moon and extend human exploration beyond the Earth-Moon system ahead of exploring Mars. These Artemis partners are developing a portfolio of space and surface systems to support human missions to the lunar surface and beyond. The Artemis systems will provide the mobility, habitation, and logistics infrastructure that will support human exploration and foster robust scientific investigations. Each partner will contribute one or more elements to the Artemis Program with NASA having the overarching responsibility for defining the Artemis architecture and guiding the integration of this complex system of space systems. To successfully accomplish this audacious task, NASA will rely on the development and execution of many complex models and simulations. Many of these simulations will be provided by the Artemis partners. While each of these simulations will provide important insight into the characteristics and performance of an associated system, individually they will not provide insight into the integrated performance of the architecture and the system of systems working in concert to execute a given Artemis mission. To address this need, NASA is developing a distributed simulation capability called the Artemis Distributed Simulation (ADS). ADS’s distributed nature supports the complex aggregation of constituent Artemis element simulations. Artemis partner simulations will be able to join into an ADS-based distributed simulation and interact with other Artemis element simulations while limiting the exposure of proprietary designs and data. ADS is defining a distributed simulation capability built on international simulation interoperability standards, specifically the High Level Architecture (HLA) and the Space Reference Federation Object Model (SpaceFOM). While HLA and SpaceFOM provide the substantive necessary technology basis for ADS, additional common datatypes, message definitions, and execution protocols are required. These extensions constitute the ADS Federation Object Model (FOM). This paper describes the fundamental architectural elements of ADS and the FOM extensions needed to support the complex nature of the Artemis Program. This includes the examination of the ADS FOM modules, ADS base datatypes, ADS SpaceFOM Object Class extensions, new ADS Object Classes, and new ADS Interaction Classes.

HLA↗

NASA Small Spacecraft Technology Program (SSTP) Overview, Recent Technology Demonstrations, and Upcoming SSTP Demonstrations

The Small Spacecraft Technology Program (SSTP) within the NASA Space Technology Mission Directorate (STMD) is chartered to enable mission capabilities that are more rapid, more transformative, and more affordable than previously achievable. To that end, the SST program seeks to: • Enable the execution of missions at much lower cost than previously possible. • Substantially reduce the time required for development of spacecraft, from authority to proceed until initial launch capability. • Enable and demonstrate new mission architectures that small spacecraft are uniquely suited for. • Expand the capability of small spacecraft to execute missions at new destinations and in challenging new environments. • Enable the augmentation of existing assets and future missions with supporting small spacecraft. This paper will describe the NASA SSTP SmallSat Technology Partnerships (STP), completed and upcoming Missions Capability Demonstrations for technology demonstrations under SSTP1 and provides a synopsis of the leveraged investments under the Small Business Innovation Research (SBIR) Program and Small Business Technology Transfer (STTR). A brief overview of the Small Spacecraft Systems Virtual Institute (S3VI) and its current activities performed in conjunction with SSTP is also provided.

Roger C. Hunter↗

Independent Configurable Architecture for Reliable Operation of Unmanned Systems with Distributed Onboard Services

This paper presents the development of ICAROUS-2 (Independent Configurable Architecture for Reliable Operation of Unmanned Systems with Distributed Onboard Services), the second generation of a software architecture that integrates several algorithms as distributed onboard services to enable robust autonomous UAS applications. In particular, the ICAROUS architecture defines a framework to perform detect and avoid, geofencing, path monitoring, path planning, and autonomous decision making to ensure safety and mission progress. Most of the core algorithms implemented in ICAROUS are formally verified using an interactive theorem prover. These algorithms are composed together using a plan execution engine, whose operational semantics is formally specified. A description of the integrated architecture, services currently available, and flight test results highlighting the capability of ICAROUS are presented.

Balachandran, Swee↗

Independent Configurable Architecture for Reliable Operation of Unmanned Systems with Distributed Onboard Services

This paper presents the development of ICAROUS-2 (Independent Configurable Architecture for Reliable Operation of Unmanned Systems with Distributed Onboard Services), the second generation of a software architecture that integrates several algorithms as distributed onboard services to enable robust autonomous UAS applications. In particular, the ICAROUS architecture defines a framework to perform detect and avoid, geofencing, path monitoring, path planning, and autonomous decision making to ensure safety and mission progress. Most of the core algorithms implemented in ICAROUS are formally verified using an interactive theorem prover. These algorithms are composed together using a plan execution engine, whose operational semantics is formally specified. A description of the integrated architecture, services currently available, and flight test results highlighting the capability of ICAROUS are presented.

Balachandran, Swee↗

Mission Assurance: A Model-Based Approach

The purpose of Safety and Mission Assurance (SMA) at NASA’s Jet Propulsion Laboratory is to ensure mission safety and success. As the complexity of technical systems increases, the tools, processes, and infrastructure used to facilitate SMA activities must evolve. A transition from a document-centric approach to a data-driven, model-based architecture is critical in allowing SMA efforts to grapple with complex system designs. This work describes how a sample subset of existing SMA processes can be executed in a model-based environment, while also describing ways in which a model-based architecture can further augment SMA efforts. One key aspect is supporting the complex interplay between the different SMA processes and the systems engineering effort to provide additional insight into the system from an SMA perspective. The proposed architecture for model-based mission assurance provides an avenue for assuring mission safety and success in increasingly complex systems.

Schreiner, Samuel S.↗

The NASA Integrated Information Technology Architecture

This document defines an Information Technology Architecture for the National Aeronautics and Space Administration (NASA), where Information Technology (IT) refers to the hardware, software, standards, protocols and processes that enable the creation, manipulation, storage, organization and sharing of information. An architecture provides an itemization and definition of these IT structures, a view of the relationship of the structures to each other and, most importantly, an accessible view of the whole. It is a fundamental assumption of this document that a useful, interoperable and affordable IT environment is key to the execution of the core NASA scientific and project competencies and business practices. This Architecture represents the highest level system design and guideline for NASA IT related activities and has been created on the authority of the NASA Chief Information Officer (CIO) and will be maintained under the auspices of that office. It addresses all aspects of general purpose, research, administrative and scientific computing and networking throughout the NASA Agency and is applicable to all NASA administrative offices, projects, field centers and remote sites. Through the establishment of five Objectives and six Principles this Architecture provides a blueprint for all NASA IT service providers: civil service, contractor and outsourcer. The most significant of the Objectives and Principles are the commitment to customer-driven IT implementations and the commitment to a simpler, cost-efficient, standards-based, modular IT infrastructure. In order to ensure that the Architecture is presented and defined in the context of the mission, project and business goals of NASA, this Architecture consists of four layers in which each subsequent layer builds on the previous layer. They are: 1) the Business Architecture: the operational functions of the business, or Enterprise, 2) the Systems Architecture: the specific Enterprise activities within the context of IT systems, 3) the Technical Architecture: a common, vendor-independent framework for design, integration and implementation of IT systems and 4) the Product Architecture: vendor=specific IT solutions. The Systems Architecture is effectively a description of the end-user "requirements". Generalized end-user requirements are discussed and subsequently organized into specific mission and project functions. The Technical Architecture depicts the framework, and relationship, of the specific IT components that enable the end-user functionality as described in the Systems Architecture. The primary components as described in the Technical Architecture are: 1) Applications: Basic Client Component, Object Creation Applications, Collaborative Applications, Object Analysis Applications, 2) Services: Messaging, Information Broker, Collaboration, Distributed Processing, and 3) Infrastructure: Network, Security, Directory, Certificate Management, Enterprise Management and File System. This Architecture also provides specific Implementation Recommendations, the most significant of which is the recognition of IT as core to NASA activities and defines a plan, which is aligned with the NASA strategic planning processes, for keeping the Architecture alive and useful.

Baldridge, Tim↗

Task scheduling in dataflow computer architectures

Dataflow computers provide a platform for the solution of a large class of computational problems, which includes digital signal processing and image processing. Many typical applications are represented by a set of tasks which can be repetitively executed in parallel as specified by an associated dataflow graph. Research in this area aims to model these architectures, develop scheduling procedures, and predict the transient and steady state performance. Researchers at NASA have created a model and developed associated software tools which are capable of analyzing a dataflow graph and predicting its runtime performance under various resource and timing constraints. These models and tools were extended and used in this work. Experiments using these tools revealed certain properties of such graphs that require further study. Specifically, the transient behavior at the beginning of the execution of a graph can have a significant effect on the steady state performance. Transformation and retiming of the application algorithm and its initial conditions can produce a different transient behavior and consequently different steady state performance. The effect of such transformations on the resource requirements or under resource constraints requires extensive study. Task scheduling to obtain maximum performance (based on user-defined criteria), or to satisfy a set of resource constraints, can also be significantly affected by a transformation of the application algorithm. Since task scheduling is performed by heuristic algorithms, further research is needed to determine if new scheduling heuristics can be developed that can exploit such transformations. This work has provided the initial development for further long-term research efforts. A simulation tool was completed to provide insight into the transient and steady state execution of a dataflow graph. A set of scheduling algorithms was completed which can operate in conjunction with the modeling and performance tools previously developed. Initial studies on the performance of these algorithms were done to examine the effects of application algorithm transformations as measured by such quantities as number of processors, time between outputs, time between input and output, communication time, and memory size.

Katsinis, Constantine↗

Applicative architectures for fault-tolerant multiprocessors

This paper proposes functional programming frameworks for the design of highly reliable multiprocessor systems. In contrast to imperative programming environments, a functional environment offers elegant, relatively simple, and efficient solutions to concurrent error detection and recovery problems in multiprocessors. Specific fault tolerance mechanisms for upset exposure, fault containment, secure task assignment, and recovery are developed for a class of applicative multiprocessor architectures. Verification of abstract behavioral characteristics of applicative tasks is used for exposing faults during the execution of tasks. The fault containment mechanism is based on isolation of stack and heap segments of tasks. A protocol for secure task assignment is defined between system components. The architecture permits incremental, distributed, and asynchronous backups of system state. Finally, recovery is accomplished, even in the worst cases, by reexecution of a small number of tasks.

Sharma, Madhumitra↗

An introduction to autonomous control systems

The functions, characteristics, and benefits of autonomous control are outlined. An autonomous control functional architecture for future space vehicles that incorporates the concepts and characteristics described is presented. The controller is hierarchical, with an execution level (the lowest level), coordination level (middle level), and management and organization level (highest level). The general characteristics of the overall architecture, including those of the three levels, are explained, and an example to illustrate their functions is given. Mathematical models for autonomous systems, including 'logical' discrete event system models, are discussed. An approach to the quantitative, systematic modeling, analysis, and design of autonomous controllers is also discussed. It is a hybrid approach since it uses conventional analysis techniques based on difference and differential equations and new techniques for the analysis of the systems described with a symbolic formalism such as finite automata. Some recent results from the areas of planning and expert systems, machine learning, artificial neural networks, and the area restructurable controls are briefly outlined.

Antsaklis, Panos J.↗

Grid Task Execution

IPG Execution Service is a framework that reliably executes complex jobs on a computational grid, and is part of the IPG service architecture designed to support location-independent computing. The new grid service enables users to describe the platform on which they need a job to run, which allows the service to locate the desired platform, configure it for the required application, and execute the job. After a job is submitted, users can monitor it through periodic notifications, or through queries. Each job consists of a set of tasks that performs actions such as executing applications and managing data. Each task is executed based on a starting condition that is an expression of the states of other tasks. This formulation allows tasks to be executed in parallel, and also allows a user to specify tasks to execute when other tasks succeed, fail, or are canceled. The two core components of the Execution Service are the Task Database, which stores tasks that have been submitted for execution, and the Task Manager, which executes tasks in the proper order, based on the user-specified starting conditions, and avoids overloading local and remote resources while executing tasks.

Hu, Chaumin↗

Planning and Execution for Front Delineation and Tracking with Multiple Underwater Vehicles

This work describes a planning architecture for a heterogeneous fleet of marine assets as well as a method for detecting and tracking ocean fronts using multiple autonomous underwater vehicles. Multiple vehicles — equally-spaced along the expected frontal boundary — complete near parallel transects orthogonal to the front. Lateral gradients are used to determine the location of the front crossing from each individual vehicle transect by detecting a change in the observed water property. Adaptive control of the vehicles ensure they remain perpendicular to the estimated frontal boundary as it evolves over time. This method was demonstrated in several experiment periods totaling weeks, in and around Monterey Bay, California in May and June of 2017. We discuss the challenges associated with the implementation of the planning system. We show the capability of this method for repeated sampling across a dynamic two-dimensional ocean front using a fleet of three types of platforms: short-range Iver AUVs, Tethys-Class Long-Range AUVs, and Seagliders. This method extends to tracking gradients of different properties using a variety of vehicles.

Chavez, Francisco P.↗

A Systems Engineering Approach to Architecture Development

Architecture development is conducted prior to system concept design when there is a need to determine the best-value mix of systems that works collectively in specific scenarios and time frames to accomplish a set of mission area objectives. While multiple architecture frameworks exist, they often require use of unique taxonomies and data structures. In contrast, this presentation characterizes architecture development using terminology widely understood within the systems engineering community. Using a notional civil space architecture example, it employs a multi-tier framework to describe the enterprise level architecture and illustrates how results of lower tier, mission area architectures integrate into the enterprise architecture. It also presents practices for conducting effective mission area architecture studies, including establishing the trade space, developing functions and metrics, evaluating the ability of potential design solutions to meet the required functions, and expediting study execution through the use of iterative design cycles.

Architecture Development↗

A Systems Engineering Approach to Architecture Development

Architecture development is often conducted prior to system concept design when there is a need to determine the best-value mix of systems that works collectively in specific scenarios and time frames to accomplish a set of mission area objectives. While multiple architecture frameworks exist, they often require use of unique taxonomies and data structures. In contrast, this paper characterizes architecture development using terminology widely understood within the systems engineering community. Using a notional civil space architecture example, it employs a multi-tier framework to describe the enterprise level architecture and illustrates how results of lower tier, mission area architectures integrate into the enterprise architecture. It also presents practices for conducting effective mission area architecture studies, including establishing the trade space, developing functions and metrics, evaluating the ability of potential design solutions to meet the required functions, and expediting study execution through the use of iterative design cycles

Architecture Development↗