Search NASA⌕ Search

SEARCH · Search NASA

Results for “software architecture design subsystem”

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 109 records · Page 6
All sourcesNASA NTRSDOE OSTI
NASA NTRS2008

Cassini Attitude Control Flight Software: from Development to In-Flight Operation

The Cassini Attitude and Articulation Control Subsystem (AACS) Flight Software (FSW) has achieved its intended design goals by successfully guiding and controlling the Cassini-Huygens planetary mission to Saturn and its moons. This paper describes an overview of AACS FSW details from early design, development, implementation, and test to its fruition of operating and maintaining spacecraft control over an eleven year prime mission. Starting from phases of FSW development, topics expand to FSW development methodology, achievements utilizing in-flight autonomy, and summarize lessons learned during flight operations which can be useful to FSW in current and future spacecraft missions.

Architecture↗
NASA NTRS1991

The AI Bus architecture for distributed knowledge-based systems

The AI Bus architecture is layered, distributed object oriented framework developed to support the requirements of advanced technology programs for an order of magnitude improvement in software costs. The consequent need for highly autonomous computer systems, adaptable to new technology advances over a long lifespan, led to the design of an open architecture and toolbox for building large scale, robust, production quality systems. The AI Bus accommodates a mix of knowledge based and conventional components, running on heterogeneous, distributed real world and testbed environment. The concepts and design is described of the AI Bus architecture and its current implementation status as a Unix C++ library or reusable objects. Each high level semiautonomous agent process consists of a number of knowledge sources together with interagent communication mechanisms based on shared blackboards and message passing acquaintances. Standard interfaces and protocols are followed for combining and validating subsystems. Dynamic probes or demons provide an event driven means for providing active objects with shared access to resources, and each other, while not violating their security.

Schultz, Roger D.↗
NASA NTRSDate not supplied

The Ejectable Data Recorder: A Lean, Risk-Informed Approach for Hardware Development

NASA is developing the Orion spacecraft to transport crew from the Earth to the Moon as part of the Artemis series of missions. To provide a crew escape capability from pre-launch through ascent, the Orion vehicle is equipped with a Launch Abort System (LAS), built by Lockheed Martin, which pulls the capsule away from the launch vehicle in the event of an abort scenario. The Ascent Abort 2 (AA-2) test flight occurred on July 2, 2019,and tested a production version of the LAS to ensure that it can operate as intended, and to collect a large data set from hundreds of sensors on the vehicle to support Orion flight certification. In the original AA-2 architecture, a single-string set of communications antennas on the LAS would downlink all of the in-flight test data to ground stations. However, that communications architecture was predicted to have data dropouts during abort and jettison of the LAS, and would not support data transmission at all after LAS jettison. As a result, a comprehensive trade study was completed, yielding the addition of antennas on the crew module (CM), a buffer/rebroadcast capability for key portions of the flight, and an ejectable data recorder (EDR) subsystem. This EDR subsystem would serve as a backup to the radio frequency (RF) communications system, and would be non-flight critical, providing a unique capability that enabled management to take a different approach with the hardware and software development. The Crew Module and Separation Ring were developed as “Class 1”Flight Hardware, albeit with some tailoring approaches to enable efficiencies. The Class 1 designation requires full rigor for flight hardware and software, documenting everything that happens to a piece of hardware from procurement through disposal, requiring a full spectrum of acceptance tests, and the highest rigor of quality assurance processes. At the other end of the spectrum, Class 3hardware is controlled, but not intended for flight, and leaves the level of rigor up to the project manager. This classification is often used for research and development projects. Similarly,Class-1E has been recently defined at NASA for ISS payloads and technology development projects that are not flight critical and do not need the full rigor of Class 1 to be successful. The EDR subsystem was challenged at commencement to adopt a skunkworks and agile-like approach to hardware development, allowing for a different risk posture than the rest of the AA-2 hardware. After initially pursuing Class 1 processes, the EDR subsystem design evolved to incorporating numerous commercial components, leading to re-designation as a Class-1E subsystem. The resulting EDR subsystem was fully successful in meeting all flight system requirements, and achieved 100% retrieval of flight test data. This paper will discuss the risk posture of the EDR subsystem and the subsequent tailoring that was enacted as part of its Class-1E status.

EDR↗
NASA NTRS1993

Future space transportation system architecture avionics requirements

NASA began a multi-center study in January 1993 to examine options for providing the most cost effective space transportation system in the future. The key advanced avionics requirements for these vehicle concepts are envisioned to provide significantly improved operational efficiency and effectiveness. It is very desirable to have adaptive guidance, navigation, and control approaches that will allow launch and return in almost any weather condition. The vehicles must be able to accommodate atmospheric density variations and winds without software changes. The flight operations must become much more autonomous in all flight regimes like an aircraft, and preflight checkout should make use of the onboard systems. When the vehicle returns to the launch site, subsystem health must be known and maintenance tasks scheduled accordingly. Ground testing of most subsystems must be eliminated. Also, the health monitoring system must be designed to enhance the ability to abort the mission significantly and save the crew and the vehicle. The displays and controls must be much less complex than current systems and must significantly reduce pilot work load. It is important to have low power, light weight displays and controls. Rendezvous and docking and all flight phases must have autopilot capability to reduce pilot work load for routine operations and in abort situations. The vehicles must have the demonstrated ability to return to the launch site. Abort from all mission phases can put additional demands on the communications system.

Stone, Howard↗
NASA NTRS2006

Crew Launch Vehicle (CLV) Upper Stage Configuration Selection Process

The Crew Launch Vehicle (CLV), a key component of NASA's blueprint for the next generation of spacecraft to take humans back to the moon, is being designed and built by engineers at NASA s Marshall Space Flight Center (MSFC). The vehicle s design is based on the results of NASA's 2005 Exploration Systems Architecture Study (ESAS), which called for development of a crew-launch system to reduce the gap between Shuttle retirement and Crew Exploration Vehicle (CEV) Initial Operating Capability, identification of key technologies required to enable and significantly enhance these reference exploration systems, and a reprioritization of near- and far-term technology investments. The Upper Stage Element (USE) of the CLV is a clean-sheet approach that is being designed and developed in-house, with element management at MSFC. The USE concept is a self-supporting cylindrical structure, approximately 115' long and 216" in diameter, consisting of the following subsystems: Primary Structures (LOX Tank, LH2 Tank, Intertank, Thrust Structure, Spacecraft Payload Adaptor, Interstage, Forward and Aft Skirts), Secondary Structures (Systems Tunnel), Avionics and Software, Main Propulsion System, Reaction Control System, Thrust Vector Control, Auxiliary Power Unit, and Hydraulic Systems. The ESAS originally recommended a CEV to be launched atop a four-segment Space Shuttle Main Engine (SSME) CLV, utilizing an RS-25 engine-powered upper stage. However, Agency decisions to utilize fewer CLV development steps to lunar missions, reduce the overall risk for the lunar program, and provide a more balanced engine production rate requirement prompted engineers to switch to a five-segment design with a single Saturn-derived J-2X engine. This approach provides for single upper stage engine development for the CLV and an Earth Departure Stage, single Reusable Solid Rocket Booster (RSRB) development for the CLV and a Cargo Launch Vehicle, and single core SSME development. While the RSRB design has changed since the CLV Project's inception, the USE design has remained essentially a clean-sheet approach. Although a clean-sheet upper stage design inherently carries more risk than a modified design, it does offer many advantages: a design for increased reliability; built-in extensibility to allow for commonality/growth without major redesign; and incorporation of state-of-the-art materials, hardware, and design, fabrication, and test techniques and processes to facilitate a potentially better, more reliable system. Because consideration was given in the ESAS to both clean-sheet and modified USE designs, this paper will highlight the advantages and disadvantages of both approaches and provide a detailed discussion of trades/selections made that led to the final upper stage configuration.

Davis, Daniel J.↗
NASA NTRS2009

Tele-Supervised Adaptive Ocean Sensor Fleet

The Tele-supervised Adaptive Ocean Sensor Fleet (TAOSF) is a multi-robot science exploration architecture and system that uses a group of robotic boats (the Ocean-Atmosphere Sensor Integration System, or OASIS) to enable in-situ study of ocean surface and subsurface characteristics and the dynamics of such ocean phenomena as coastal pollutants, oil spills, hurricanes, or harmful algal blooms (HABs). The OASIS boats are extended- deployment, autonomous ocean surface vehicles. The TAOSF architecture provides an integrated approach to multi-vehicle coordination and sliding human-vehicle autonomy. One feature of TAOSF is the adaptive re-planning of the activities of the OASIS vessels based on sensor input ( smart sensing) and sensorial coordination among multiple assets. The architecture also incorporates Web-based communications that permit control of the assets over long distances and the sharing of data with remote experts. Autonomous hazard and assistance detection allows the automatic identification of hazards that require human intervention to ensure the safety and integrity of the robotic vehicles, or of science data that require human interpretation and response. Also, the architecture is designed for science analysis of acquired data in order to perform an initial onboard assessment of the presence of specific science signatures of immediate interest. TAOSF integrates and extends five subsystems developed by the participating institutions: Emergent Space Tech - nol ogies, Wallops Flight Facility, NASA s Goddard Space Flight Center (GSFC), Carnegie Mellon University, and Jet Propulsion Laboratory (JPL). The OASIS Autonomous Surface Vehicle (ASV) system, which includes the vessels as well as the land-based control and communications infrastructure developed for them, controls the hardware of each platform (sensors, actuators, etc.), and also provides a low-level waypoint navigation capability. The Multi-Platform Simulation Environment from GSFC is a surrogate for the OASIS ASV system and allows for independent development and testing of higher-level software components. The Platform Communicator acts as a proxy for both actual and simulated platforms. It translates platform-independent messages from the higher control systems to the device-dependent communication protocols. This enables the higher-level control systems to interact identically with heterogeneous actual or simulated platforms.

Lefes, Alberto↗
NASA NTRS2010

The Orion GN and C Data-Driven Flight Software Architecture for Automated Sequencing and Fault Recovery

The Orion Crew Exploration Vehicle (CET) is being designed to include significantly more automation capability than either the Space Shuttle or the International Space Station (ISS). In particular, the vehicle flight software has requirements to accommodate increasingly automated missions throughout all phases of flight. A data-driven flight software architecture will provide an evolvable automation capability to sequence through Guidance, Navigation & Control (GN&C) flight software modes and configurations while maintaining the required flexibility and human control over the automation. This flexibility is a key aspect needed to address the maturation of operational concepts, to permit ground and crew operators to gain trust in the system and mitigate unpredictability in human spaceflight. To allow for mission flexibility and reconfrgurability, a data driven approach is being taken to load the mission event plan as well cis the flight software artifacts associated with the GN&C subsystem. A database of GN&C level sequencing data is presented which manages and tracks the mission specific and algorithm parameters to provide a capability to schedule GN&C events within mission segments. The flight software data schema for performing automated mission sequencing is presented with a concept of operations for interactions with ground and onboard crew members. A prototype architecture for fault identification, isolation and recovery interactions with the automation software is presented and discussed as a forward work item.

King, Ellis↗
NASA NTRS2011

Towards a State Based Control Architecture for Large Telescopes: Laying a Foundation at the VLT

Large telescopes are characterized by a high level of distribution of control-related tasks and will feature diverse data flow patterns and large ranges of sampling frequencies; there will often be no single, fixed server-client relationship between the control tasks. the architecture is also challenged by the task of integrating heterogeneous subsystems which will be delivered by multiple different contractors. Due to the high number of distributed components, the control system needs to effectively detect errors and faults, impede their propagation, and accurately mitigate them in the shortest time possible, enabling the service to be restored. The presented Data-Driven Architecture is based on a decentralized approach with an end-to-end integration of disparate, independently developed software components. These components employ a high-performance standards-based communication middle-ware infrastructure, based on the Data Distribution Service. A set of rules and principles, based on JPL's State Analysis method and architecture, are use to constrain component-to component interactions, where the Control System and System Under Control are clearly separated. State Analysis provide a model-based process for capturing system and software requirements and design, greatly reducing the gap between the requirements on software specified by systems engineers and the implementation by software engineers. The method and architecture has been field tested at the Very Large Telescope, where it has been integrated into an operational system.

European Extremely Large Telescope (E-ELT)↗
NASA NTRS2014

Enhanced International Space Station Ku-Band Telemetry Service

The International Space Station (ISS) is in an operational configuration. To fully utilize the ISS and take advantage of the modern protocols and updated Ku-band access, the Huntsville Operations Support Center (HOSC) has designed an approach to extend the Kuband forward link access for payload investigators to their on-orbit payloads. This dramatically increases the ground to ISS communications for those users. This access also enables the ISS flight controllers operating in the Payload Operations and Integration Center to have more direct control over the systems they are responsible for managing and operating. To extend the Ku-band forward link to the payload user community the development of a new command server is necessary. The HOSC subsystems were updated to process the Internet Protocol Encapsulated packets, enable users to use the service based on their approved services, and perform network address translation to insure that the packets are forwarded from the user to the correct payload repeating that process in reverse from ISS to the payload user. This paper presents the architecture, implementation, and lessons learned. This will include the integration of COTS hardware and software as well as how the device is incorporated into the operational mission of the ISS. Thus, this paper also discusses how this technology can be applicable to payload users of the ISS.

Cecil, Andrew J.↗
NASA NTRS2016

JPL's Foundry Furnace: Web-Based Concurrent Engineering for Formulation

The Jet Propulsion Laboratory’s Innovation Foundry is an enterprise tasked with shepherding space mission concepts through the formulation lifecycle. It oversees a number of “virtual teams” for the various stages of formulation. Among these is Team X, which has had considerable success over its more than 20-year history. In a Team X study, domain experts (including engineers devoted to the various spacecraft subsystems) work concurrently and collaboratively over several days to arrive at a feasible point design with a reasonable cost estimate. They use a set of linked Excel workbooks, each developed and approved by a responsible “line organization” within JPL. This toolset has served Team X well over the years, and has evolved since its inception. At the same time, the Innovation Foundry’s portfolio of formulation teams has expanded, and so has the scope of the design challenges they face. The A-Team runs workshop-like architecture studies to focus science investigations, generate mission concepts, assess feasibility, and explore trade spaces. Team Xc performs rapid point design in the style of Team X, but for CubeSats and small spacecraft, using a different toolset. Proposal teams further mature concepts to the point where they can be proposed. Recognizing the importance of trade space modeling combined with new IT services for providing and integrating data, JPL is developing the Foundry Furnace web-based software infrastructure. It will support A-Team, Team Xc, and Team X, providing study management, a catalog of hardware components, a library of re-usable analyses, and a design environment. It is a modernization of JPL’s concurrent engineering infrastructure, embracing the core concepts of Model-Based Systems Engineering, and built with modern software design philosophies.

Murphy, Jonathan↗
NASA NTRSDate not supplied

A Comparison of Model Predictive Control Architectures for Application to Electrified Aircraft Propulsion Systems

As electrified aircraft propulsion (EAP) systems continue to mature, more sophisticated hardware and software are being developed to balance operations among electric machines and gas-turbine engines. In hybrid-electric propulsion systems, the increased complexity resulting from integrating turbine-engine shafts with electric machines necessitates control methodologies to account for various physical domains. Ideal controllers for hybrid-electric engines manage systems, subsystems, and their interactions in a coordinated fashion, able to account for safety and performance goals while being computationally efficient. In a previous work, linear model predictive control (MPC) schemes were implemented in centralized and distributed frameworks on a nonlinear turbofan engine model as a proof of concept. However, these schemes were not evaluated for computational complexity, prompting further study. The research presented here develops hierarchical MPC schemes to reduce the computational burden of the previous MPC schemes. A two-tier framework is implemented, where a slower sampling MPC controls electric machines and determines fan-speed tracking goals for a faster sampling controller, which is either a MPC or a proportional-integral (PI) controller. The proposed designs are compared to the centralized MPC investigated previously, and performance is measured via fan speed tracking error, energy storage state-of-charge, and computation time. Results reveal that the hierarchical MPC scheme employing a lower-level PI controller improves computation time while maintaining comparable tracking and state-of-charge regulation to the centralized scheme.

model predictive control↗
NASA NTRSDate not supplied

A Comparison of Model Predictive Control Architectures for Application to Electrified Aircraft Propulsion Systems

As electrified aircraft propulsion (EAP) systems continue to mature, more sophisticated hardware and software are being developed to balance operations among electric machines and gas-turbine engines. In hybrid-electric propulsion systems, the increased complexity resulting from integrating turbine-engine shafts with electric machines necessitates control methodologies to account for various physical domains. Ideal controllers for hybrid-electric engines manage systems, subsystems, and their interactions in a coordinated fashion, able to account for safety and performance goals while being computationally efficient. In a previous work, linear model predictive control (MPC) schemes were implemented in centralized and distributed frameworks on a nonlinear turbofan engine model as a proof of concept. However, these schemes were not evaluated for computational complexity, prompting further study. The research presented here develops hierarchical MPC schemes to reduce the computational burden of the previous MPC schemes. A two-tier framework is implemented, where a slower sampling MPC controls electric machines and determines fan-speed tracking goals for a faster sampling controller, which is either a MPC or a proportional-integral (PI) controller. The proposed designs are compared to the centralized MPC investigated previously, and performance is measured via fan speed tracking error, energy storage state-of-charge, and computation time. Results reveal that the hierarchical MPC scheme employing a lower-level PI controller improves computation time while maintaining comparable tracking and state-of-charge regulation to the centralized scheme.

model predictive control↗
NASA NTRS2025

HabSim: A Modular Coupled Virtual Testbed for Simulating ExtraTerrestrial Habitat Systems

Extraterrestrial habitats involve a tightly coupled combination of hardware, software, and humans while operating in an unforgiving environment that poses many risks, both anticipated and unanticipated. Traditional approaches with such systems of systems focus on reliability, robustness, and redundancy. These approaches seek to avoid failure rather than reduce overall risk. However, faults are inevitable, and understanding and managing the complex and emergent behavior and cascading events of such a complex system is critical. This study describes the development of HabSim, a computational simulation environment intended to support research to establish the know-how to design and operate resilient and autonomous SmartHabs. HabSim is a modular virtual testbed composed of many of the coupled dynamic systems expected in a typical SmartHab. A heterogeneous set of interconnected physics-based and phenomenological models is used to represent the essential functions of a SmartHab. HabSim further considers disruptions and models damage and repair of certain components. This paper discusses a) system and subsystem requirements of the deep space habitat included in the HabSim platform; b) architectural choices made in response to the requirements; c) technical considerations for developing, verifying, configuring, and executing HabSim; and d) illustrative sample results from a simulation of a representative disruption scenario.

Mohsen Azimi↗
NASA NTRS1994

Evaluation of NASA's end-to-end data systems using DSDS+

The Data Systems Dynamic Simulator (DSDS+) is a software tool being developed by the authors to evaluate candidate architectures for NASA's end-to-end data systems. Via modeling and simulation, we are able to quickly predict the performance characteristics of each architecture, to evaluate 'what-if' scenarios, and to perform sensitivity analyses. As such, we are using modeling and simulation to help NASA select the optimal system configuration, and to quantify the performance characteristics of this system prior to its delivery. This paper is divided into the following six sections: (1) The role of modeling and simulation in the systems engineering process. In this section, we briefly describe the different types of results obtained by modeling each phase of the systems engineering life cycle, from concept definition through operations and maintenance; (2) Recent applications of DSDS+. In this section, we describe ongoing applications of DSDS+ in support of the Earth Observing System (EOS), and we present some of the simulation results generated of candidate system designs. So far, we have modeled individual EOS subsystems (e.g. the Solid State Recorders used onboard the spacecraft), and we have also developed an integrated model of the EOS end-to-end data processing and data communications systems (from the payloads onboard to the principle investigator facilities on the ground); (3) Overview of DSDS+. In this section we define what a discrete-event model is, and how it works. The discussion is presented relative to the DSDS+ simulation tool that we have developed, including it's run-time optimization algorithms that enables DSDS+ to execute substantially faster than comparable discrete-event simulation tools; (4) Summary. In this section, we summarize our findings and 'lessons learned' during the development and application of DSDS+ to model NASA's data systems; (5) Further Information; and (6) Acknowledgements.

Rouff, Christopher↗
NASA NTRS2018

Software System for the Mars 2020 Mission Sampling and Caching Testbeds

The development of the Sampling and Caching Subsystem (SCS) of the Mars 2020 Rover Mission is highly dependent on testing of prototype hardware and software operating in explicit conditions as part of integrated testbeds. To achieve relevant integration of hardware and software while maintaining rapid algorithm development capabilities and high testing throughput, the Controls and Autonomy for Sample Acquisition and Handling (CASAH) software system was developed. CASAH is an implementation of the Intelligent Robotics System Architecture (IRSA),which mimics JPL Flight Software (FSW) in that it is divided into hierarchical modules that run separate processes that communicate via message passing, each module is assigned an owner that is a single developer, and the operator initiates requests via a text-based interface that interprets sequences of commands.IRSA enables a modular breakdown of CASAH that follows that of 2020 Flight Software,so developers can take an algorithm from a module in CASAH and re-code it into the same module in FSW. As deployment of CASAH has grown to ten testbeds - each with different hardware and objectives - bottom-up design decisions have been intentionally made to keep the system lightweight and maintainable by a very small team. To date, CASAH has been used to run 1393 different tests. This work describes CASAH, the testbeds and functionality it supports, the tools used to manage the development and sharing of code, and the features of the software. Lessons learned over the past three years of development and deployment are provided.

Vieira, Peter↗
NASA NTRS2018

Development of a Ground Test and Analysis Protocol for NASA's NextSTEP Phase 2 Habitation Concepts

The NASA Next Space Technologies for Exploration Partnerships (NextSTEP) program is a public-private partnership model that seeks commercial development of deep space exploration capabilities to support human spaceflight missions around and beyond cislunar space. NASA first issued the Phase 1 NextSTEP Broad Agency Announcement to U.S. industries in 2014, which called for innovative cislunar habitation concepts that leveraged commercialization plans for low-Earth orbit. These habitats will be part of the Deep Space Gateway (DSG), the cislunar space station planned by NASA for construction in the 2020s. In 2016, Phase 2 of the NextSTEP program selected five commercial partners to develop ground prototypes. A team of NASA research engineers and subject matter experts (SMEs) have been tasked with developing the ground-test protocol that will serve as the primary means by which these Phase 2 prototypes will be evaluated. Since 2008, this core test team has successfully conducted multiple spaceflight analog mission evaluations utilizing a consistent set of operational tools, methods, and metrics to enable the iterative development, testing, analysis, and validation of evolving exploration architectures, operations concepts, and vehicle designs. The purpose of implementing a similar evaluation process for the Phase 2 Habitation Concepts is to consistently evaluate different commercial partner ground prototypes to provide data-driven, actionable recommendations for Phase 3. This paper describes the process by which the ground test protocol was developed and the objectives, methods, and metrics by which the NextSTEP Phase 2 Habitation Concepts will be rigorously and systematically evaluated. The protocol has been developed using both a top-down and bottom-up approach. Top-down development began with the Human Exploration and Operations Mission Directorate (HEOMD) exploration objectives and ISS Exploration Capability Study Team (IECST) candidate flight objectives. Strategic questions and associated rationales, derived from these candidate architectural objectives, provide the framework by which the ground-test protocol will address the DSG stack elements and configurations, systems and subsystems, and habitation, science, and EVA functions. From these strategic questions, high-level functional requirements for the DSG were drafted and associated ground-test objectives and analysis protocols were established. Bottom-up development incorporated objectives from NASA SMEs in autonomy, avionics and software, communication, environmental control and life support systems, exercise, extravehicular activity, exploration medical operations, guidance navigation and control, human factors and behavioral performance, human factors and habitability, logistics, Mission Control Center operations, power, radiation, robotics, safety and mission assurance, science, simulation, structures, thermal, trash management, and vehicle health. Top-down and bottom-up objectives were integrated to form overall functional requirements - ground-test objectives and analysis mapping. From this mapping, ground-test objectives were organized into those that will be evaluated through inspection, demonstration, analysis, subsystem standalone testing, and human-in-the-loop (HITL) testing. For the HITL tests, mission-like timelines, procedures, and flight rules have been developed to directly meet ground test objectives and evaluate specific functional requirements. Data collected from these assessments will be analyzed to determine the acceptability of habitation element configurations and the combinations of capabilities that will result in the best habitation platform to be recommended by the test team for Phase 3.

Gernhardt, Michael L.↗
NASA NTRS2019

A Distributed Hierarchical Framework for Autonomous Spacecraft Control

Future human space missions for exploring beyond low Earth orbit are in the conceptual design stage. One such mission describes a habitat in cis-lunar orbit that is visited by crew periodically, others describe missions to Mars. These missions have one important thing in common: the need for autonomy on the spacecraft. This need stems from the latency and bandwidth constraints on communications between the vehicle and ground control. A variable amount of autonomy may be necessary whether the spacecraft has crew on board or not. Spacecraft are complex systems that are engineered as a collection of subsystems. These subsystems work together to control the overall state of the spacecraft. As such, solutions that increase the autonomy of the spacecraft (called autonomous functions) should respect both the independence and interconnectedness of the spacecraft subsystems. This distributed and hierarchical approach to system monitoring and control is a key idea in the Modular Autonomous Systems Technology (MAST) framework. The MAST framework enables a component-based architecture that provides interfaces and structure to developing autonomous technologies. The framework enforces a distributed, hierarchical architecture for autonomous control systems across subsystems, systems, elements, and vehicles. An example autonomous system was implemented in this framework and tested using realistic spacecraft software and hardware simulations. This paper will discuss the framework, tests conducted, results, and future work.

Badger, Julia M.↗
NASA NTRS2013

Analyses Made to Order: Using Transformation to Rapidly Configure a Multidisciplinary Environment

Aerospace problems are highly multidisciplinary. Four or more major disciplines are involved in analyzing any particular vehicle. Moreover, the choice of implementation technology of various subsystems can lead to a change of leading domain or reformation of the driving equations. An excellent example is the change of expertise required to consider aircraft built from composite or metallic structures, or those propelled by chemical or electrical thrusters. Another example is in the major reconfiguration of handling and stability equations with different control surface configuration (e.g., canards, t-tail v four-post tail). Combinatorial problems are also commonplace anytime that a major system is to be designed. If there are only 5 attributes of a design to consider with 4 different options, this is already 1024 options. Adding just 5 more dimensions to the study explodes the space to over one million. Even generous assumptions like the idea that only 10% of the combinations are physically feasible can only contain the problem for so long. To make matters worse, the simple number of combinations is only the beginning. Combining the issue of trade space size with the need to reformulate the design problem for many of the possibilities makes life exponentially more difficult. Advances in software modeling approaches have led to the development of model-driven architecture. This approach uses the transformation of models into inferred models (e.g. inferred execution traces from state machines) or the skeletons for code generation. When the emphasis on transformation is applied to aerospace, it becomes possible to exploit redundancy in the information specified in multiple domain models into a unified system model. F1urther, it becomes possible to overcome the combinatorial nature of specifying integrated system behavior by manually combining the equations governing a given component technology. Transformations from a system specification combined with a system-analysis mapping specification enable one-click combination of domain analyses. This is a flexibility that has been missing from many engineering codes, which often entangle design specification and physical examination much more than is required to conduct the analysis. This capability has been investigated and cultivated within the DARPA F6 program by a team of JPL and Phoenix Integration engineers building the Adapatable Systems Design and Analysis (ASDA) framework. By embracing system modeling with SysML and the Query-View-Transformation (QVT) language, the ASDA team has been able to build a flexible, easily reconfigurable framework for building up and solving large tradespaces. Examples of application and lessons learned in building the framework will be described in this paper. In addition, the motivation will be laid for various tool vendors to develop open model description standards while being able to maintain competitive advantage through proprietary algorithms and approaches. These standards will also be compared to the underpinnings of model-driven architecture and the OMG standards of the Meta-Object Facility (MOF), SysML, and QVT.

Cole, Bjorn↗