SEARCH · Search NASA

Results for “planning scheduling 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 181 records · Page 10

All sources NASA NTRS DOE OSTI

NASA NTRSDate not supplied

Assessment of Crew Time for Maintenance and Repair Activities for Lunar Surface Missions

NASA is currently evaluating different methods to predict how much time crewmembers will spend conducting repair and maintenance activities on future space missions. As mission scope and spacecraft architectures change, understanding how crew repair and maintenance timelines are impacted by mission operations and technology changes is vital for future mission planning. Past work has been done using historical International Space Station (ISS) data to accurately predict crew habitation and operation timelines, resulting in the development of NASA’s Exploration Crew Time Model (ECTM). However, understanding crew maintenance and repair requirements has posed a unique challenge due to the complexity of available datasets, the probabilistic nature of sub-system failures, and the impacts of reliability growth on failure rates. This paper presents a methodology to collect and condition empirical repair and maintenance time data from available datasets, to extrapolate from that data to estimate projected maintenance and repair times for a lunar Surface Habitat (SH), and to assess how uncertainty in repair time could impact utilization time on the lunar surface. NASA ISS maintenance and crew time data are logged into two central databases: the Maintenance Data Collection (MDC) and the Operations Planning Timeline Integration System (OPTimIS). Separately, each of these two datasets capture only portions of the complete set of data required to generate an accurate assessment of crew time spent on maintenance activities at a sub-system level. To create a more useful crew time estimate for maintenance timelines, the authors developed a methodology to capture relevant data from each set and combine and utilize that data by linking crew time requirements to specific components. The authors compare the failure logs in the MDC to crew activity logs pulled from OPTimIS and then process the data to estimate required repair time for each failure and repair event. The entire maintenance activity dataset is then categorized based on the class of failed component to ensure a significant sample size for each class and accurate crew time estimates for any components lacking relevant data. This resultant component repair time data can be used in the future to generate Mean Time to Repair (MTTR) estimates and confidence intervals for each class of component based on a probabilistic distribution of documented maintenance events. These improved MTTR values can then be applied to candidate element sub-system architectures, along with component Mean Time Between Failure (MTBF) data to generate distributions for potential required system crew repair time estimates for a given mission. The authors applied these modeling methods to a case study of a crewed mission to the planned SH and produced expected corrective maintenance crew time distributions. The results produced an expected corrective maintenance crew time at over 24 hours per mission, and a maintenance crew time distribution that reflects the importance of planning for sufficient maintenance requirements each mission. Repair time distributions can then be used to develop more accurate crew schedules and to assess potential available utilization time.

Crew Time↗

NASA NTRS1992

Predit: A temporal predictive framework for scheduling systems

Scheduling can be formalized as a Constraint Satisfaction Problem (CSP). Within this framework activities belonging to a plan are interconnected via temporal constraints that account for slack among them. Temporal representation must include methods for constraints propagation and provide a logic for symbolic and numerical deductions. In this paper we describe a support framework for opportunistic reasoning in constraint directed scheduling. In order to focus the attention of an incremental scheduler on critical problem aspects, some discrete temporal indexes are presented. They are also useful for the prediction of the degree of resources contention. The predictive method expressed through our indexes can be seen as a Knowledge Source for an opportunistic scheduler with a blackboard architecture.

Paolucci, E.↗

NASA NTRS1999

BIO-Plex Information System Concept

This paper describes a suggested design for an integrated information system for the proposed BIO-Plex (Bioregenerative Planetary Life Support Systems Test Complex) at Johnson Space Center (JSC), including distributed control systems, central control, networks, database servers, personal computers and workstations, applications software, and external communications. The system will have an open commercial computing and networking, architecture. The network will provide automatic real-time transfer of information to database server computers which perform data collection and validation. This information system will support integrated, data sharing applications for everything, from system alarms to management summaries. Most existing complex process control systems have information gaps between the different real time subsystems, between these subsystems and central controller, between the central controller and system level planning and analysis application software, and between the system level applications and management overview reporting. An integrated information system is vitally necessary as the basis for the integration of planning, scheduling, modeling, monitoring, and control, which will allow improved monitoring and control based on timely, accurate and complete data. Data describing the system configuration and the real time processes can be collected, checked and reconciled, analyzed and stored in database servers that can be accessed by all applications. The required technology is available. The only opportunity to design a distributed, nonredundant, integrated system is before it is built. Retrofit is extremely difficult and costly.

Jones, Harry↗

NASA NTRS2014

Asteroid Redirect Crewed Mission Space Suit and EVA System Architecture Trade Study

The Asteroid Redirect Crewed Mission (ARCM) requires a Launch/Entry/Abort (LEA) suit capability and short duration Extra Vehicular Activity (EVA) capability for Orion. The EVAs will involve a two-person crew for approximately four hours. Currently, two EVAs are planned with one contingency EVA in reserve. Providing this EVA capability is very challenging due to system level constraints and a new and unknown environment. The goal of the EVA architecture for ARCM is one that builds upon previously developed technologies and lessons learned, and that accomplishes the ARCM mission while providing a stepping stone to future missions and destinations. The primary system level constraints are to 1) minimize system mass and volume and 2) minimize the interfacing impacts to the baseline Orion design. In order to minimize the interfacing impacts and to not perturb the baseline Orion schedule, the concept of adding "kits" to the baseline system is proposed. These kits consist of: an EVA kit (converts LEA suit to EVA suit), EVA Servicing and Recharge Kit (provides suit consumables), the EVA Tools, Translation Aids & Sample Container Kit (the tools and mobility aids to complete the tasks), the EVA Communications Kit (interface between the EVA radio and the MPCV), and the Cabin Repress Kit (represses the MPCV between EVAs). This paper will focus on the trade space, analysis, and testing regarding the space suit (pressure garment and life support system). Historical approaches and lessons learned from all past EVA operations were researched. Previous and current, successfully operated EVA hardware and high technology readiness level (TRL) hardware were evaluated, and a trade study was conducted for all possible pressure garment and life support options. Testing and analysis was conducted and a recommended EVA system architecture was proposed. Pressure garment options that were considered for this mission include the currently in-use ISS EVA Mobility Unit (EMU), all variations of the Advanced Crew Escape Suit (ACES), and the Exploration Z-suit. For this mission, the pressure garment that was selected is the Modified ACES (MACES) with EVA enhancements. Life support options that were considered included short closed-loop umbilicals, long open-loop umbilicals, the currently in-use ISS EMU Portable Life Support System (PLSS), and the currently in development Exploration PLSS. For this mission, the life support option that was selected is the Exploration PLSS. The greatest risk in the proposed architecture is viewed to be the comfort and mobility of the baseline MACES and the delicate balance between adding more mobility features while not compromising landing safety. Feasibility testing was accomplished in low fidelity analogs and in the JSC Neutral Buoyancy Laboratory (NBL) to validate the concept before a final recommendation on the architecture was made. The proposed architecture was found to meet the mission constraints, but much more work is required to determine the details of the required suit upgrades, the integration with the PLSS, and the rest of the tools and equipment required to accomplish the mission. This work and further definition of the remaining kits will be conducted in government fiscal year 14.

Blanco, Raul A.↗

NASA NTRS2018

Improvements to Integrated Tradespace Analysis of Communications Architectures (ITACA) Network Loading Analysis Tool

NASA's SCENIC project aims to simplify and reduce the cost of space mission planning by replicating the analysis capabilities of commercially licensed software which are integrated with relevant analysis parameters specific to SCaN assets and SCaN supported user missions. SCENIC differs from current tools that perform similar analyses in that it 1) does not require any licensing fees, 2) will provide an all-in-one package for various analysis capabilities that normally requires add-ons or multiple tools to complete. As part of SCENIC's capabilities, the ITACA network loading analysis tool will be responsible for assessing the loading on a given network architecture and generating a network service schedule. ITACA will allow users to evaluate the quality of service of a given network architecture and determine whether or not the architecture will satisfy the mission's requirements. ITACA is currently under development, and the following improvements were made during the fall of 2017: optimization of runtime, augmentation of network asset pre-service configuration time, augmentation of Brent's method of root finding, augmentation of network asset FOV restrictions, augmentation of mission lifetimes, and the integration of a SCaN link budget calculation tool. The improvements resulted in (a) 25% reduction in runtime, (b) more accurate contact window predictions when compared to STK(Registered Trademark) contact window predictions, and (c) increased fidelity through the use of specific SCaN asset parameters.

analysis↗

NASA NTRS2023

BRAINSTACK – A Platform for Artificial Intelligence & Machine Learning Collaborative Experiments on a Nano-Satellite

As the space economy continues to expand through increasingly easy access to advanced and inexpensive technology, space missions themselves have become more ambitious with exploration targets growing ever distant while simultaneously requiring larger guidance and communication budgets. These conflicting desires of distance and control drive the need for advanced on-board intelligent decision making to reduce communication and control limitations by automating as many mission functions as possible in-situ. While the amount of research on such Artificial Intelligence and Machine Learning (AI/ML) software modules has grown exponentially, the capacity to experimentally validate such software modules in space in a rapid and inexpensive format has not. To this end, the Nano Orbital Workshop (NOW) group at NASA Ames Research Center has been at the forefront of performing initial flight evaluation tests of ‘commercially’ available bleeding-edge computational platforms via what is programmatically referred to as the BrainStack on the TechEdSat (TES-n) flight series. This on-orbit computational platform provides an evaluation laboratory where advanced software experiments are pre-loaded into memory prior to launch, then executed as payloads during mission operations with results reported back and program tweaks or new training sets uploaded as needed. Processors selected as part of the BrainStack are of ideal size, packaging, and power consumption for easy integration into a cube satellite structure. These experiments have included the evaluation of small, high-performance GPUs and, more recently, neuromorphic processors, in LEO operations. Neuromorphic processors are of particular interest due to their superior power efficiency over GPUs in intelligent automation applications. The first TES-n flight test of an Intel first-generation Loihi neuromorphic processor launched on TES-13, January 13, 2022, and continues to operate in orbit despite no significant modifications to harden the processor against the space environment. The Intel Loihi Gen-1 on TES-13 is characterized by a 14nm 128-core Spiking Neural Network (SNN) able to support on-chip training. The processor is packaged in the Kapoho Bay USB module, providing a relatively straight-forward interface to the bus avionics system. The Kapoho Bay was in turn managed by an Intel Pentium single-board computer to handle scheduling of the software application payloads and communications with the satellite’s primary computer. The recently released Intel Loihi Gen-2, able to support integer-valued spike payloads and produced using 7nm process, will form part of the continually evolving BrainStack in the upcoming three TES-n/NOW flights. The Kapoho Point unit will incorporate eight Loihi-2 processors, enabling neural networks of up to one million neurons and one billion synapsis. Additionally, it is planned to measure the radiation environment these processors experience to understand any degradation or computational artifacts caused by long term space radiation exposure on these novel architectures. This evolving flexible and collaborative environment involving various research teams across NASA and other organizations is intended to be a convenient orbital test platform from which many anticipated future space automation applications may be initially tested.

Artificial Intelligence↗

NASA NTRS2006

The Mars Reconnaissance Orbiter Mission Operations: Architecture and Approach

The Mars Reconnaissance Orbiter (MRO) was launched on August 12, 2005 by an Atlas V launch vehicle from Cape Canaveral Air Force Station. MRO will carry a rich set of science instruments to Mars and provide global, regional survey, and targeted observations. In addition, a set of engineering instruments providing optical navigation, Ka band telecommunication and UHF relay services to future Mars missions are part of the MRO payload. During the mission, the MRO operations teams are presented with two major challenges - unprecedented high data rate and data volumes, and complex science planning and resource sharing. MRO has the capability to communicate with earth at a maximum of six Megabits per second (> 50 times any previous Mars missions). With the current Deep Space Network (DSN) contact schedule of 19 eight-hour tracks per week, the baseline mission plan is for MRO to return 34 Terabits of raw science data during the two year primary science phase. Each of the science instruments has its unique requirements for global mapping, regional survey, and targeted observations. Some instruments prefer nadir-only observations, while others require off-nadir observations (especially for stereo viewing). The requirements from these Mars viewing instruments presented a significant challenge for the operations team to design the complex science planning and resource sharing/allocation process. This paper describes what MRO project is implementing to solve these challenges.

Mars Reconnaissance Orbiter (MRO)↗

NASA NTRS2003

Citizen Explorer: An Earth Observer With New Small Satellite Technology - 1

Citizen Explorer-I (CX-I), designed and built by students at Colorado Space Grant Consortium in Boulder to provide global ozone monitoring, employs a unique mission architecture and several innovative technologies during its mission. The mission design allows K-12 schools around the world to be involved as ground stations available to receive science data and telemetry from CX-I. Another important technology allows the spacecraft to be less reliant on ground operators. Spacecraft Command Language (SCL) allows mission designers to set constraints on the satellite operations. The satellite then automatically adheres to the constraints when the satellite is out of contact with Mission Operations. In addition to SCL, a low level of artificial intelligence will be supplied to the spacecraft through the use of the Automated Scheduling and Planning ENvironment (ASPEN). ASPEN is used to maintain a spacecraft schedule in order to achieve the objectives a mission operator would normally have to complete. Within the communications system of CX-I, internet of CX-I, internet protocols are the main method for communicating with the satellite. As internet protocols have not been widely used in satellite communication, CX-I provides an opportunity to study the effectiveness of using internet protocols over radio links. The Attitude Determination and Control System (ADCS) on CX-I uses a gravity gradient boom as a means of orienting the satellite's science instruments toward nadir. The boom design is unique because it is constructed of tape measure material. These new technologies' effectiveness will be tested for use on future small satellite projects within the space satellite industry.

Allen, Zachary↗

NASA NTRS2010

The Habitat Demonstration Unit System Integration

The Lunar Surface System Habitat Demonstration Unit (HDU) will require a project team to integrate a variety of contributions from National Aeronautics and Space Administration (NASA) centers and potential outside collaborators and poses a challenge in integrating these disparate efforts into a cohesive architecture. To accomplish the development of the first version of the HDU, the Pressurized Excursion Module (PEM), from conception in June 2009 to rollout for operations in July 2010, the HDU project team is using several strategies to mitigate risks and bring the separate efforts together. First, a set of design standards is being developed to define the interfaces between the various systems of PEM and to the payloads, such as the Geology Laboratory, that those systems will support. Scheduled activities such as early fit-checks and the utilization of a habitat avionics test bed prior to equipment installation into HDU PEM are planned to facilitate the integration process. A coordinated effort to establish simplified Computer Aided Design (CAD) standards and the utilization of a modeling and simulation systems will aid in design and integration concept development. Finally, decision processes on the shell development including the assembly sequence and the transportation have been fleshed out early on HDU design to maximize the efficiency of both integration and field operations.

Gill, Tracy R.↗

NASA NTRS2012

Framework for Architecture Trade Study Using MBSE and Performance Simulation

Increasing complexity in modern systems as well as cost and schedule constraints require a new paradigm of system engineering to fulfill stakeholder needs. Challenges facing efficient trade studies include poor tool interoperability, lack of simulation coordination (design parameters) and requirements flowdown. A recent trend toward Model Based System Engineering (MBSE) includes flexible architecture definition, program documentation, requirements traceability and system engineering reuse. As a new domain MBSE still lacks governing standards and commonly accepted frameworks. This paper proposes a framework for efficient architecture definition using MBSE in conjunction with Domain Specific simulation to evaluate trade studies. A general framework is provided followed with a specific example including a method for designing a trade study, defining candidate architectures, planning simulations to fulfill requirements and finally a weighted decision analysis to optimize system objectives.

Ryan, Jessica↗

NASA NTRS1993

TLRS-3 system upgrades

This presentation describes the upgrades to the Transportable Laser Ranging Systems serial number three (TLRS-3), and the impact that these upgrades will have on the TLRS-3 performance in the field. The four major areas of system upgrades are the HP-380 computer, the Optical Attenuation Mechanism (OAM), the upgraded spatial, spectral and temporal filtering for improved daylight ranging capability, and the software upgrade to enable the system to track the Etalon satellites. The TLRS-3 was returned to the Goddard Geophysical and Astronomical Observatory (GGAO) in December 1991 for system upgrades in preparation of the TOPEX/POSEIDON campaign scheduled to begin in the summer of 1992. Many system upgrades were incorporated into the system while interleaving planned facility maintenance making TLRS-3 a more versatile and more dependable laser ranging system. The TLRS-3 was initially baselined with the MOBLAS-7 via simultaneous satellite ranging on the LAGEOS, Ajisai, Starlette, and ERS-I satellites. During the upgrades and following completion of the system upgrades intercomparisons with the MOBLAS-7 were made to verify the integrity and accuracy of the system changes. Several other groups of personnel participated in the TLRS-3 upgrade and they are: the Survey Section, the Precision Measurement Equipment Laboratory, the Architectural and Engineering Services Department, the Precision Timing Section, and the station personnel at TLRS-3 and MOBLAS-7.

Eichinger, Richard↗

NASA NTRS2018

Leverage Points for System Health Management of Autonomous Systems

Systems Health Management (SHM) is one of three basic functionalities that constitute an autonomous capability of a system. The other two functionalities are Planning & Scheduling, and Task Execution. In an autonomous system, variable autonomy is often distinct from variable authority to sense, decide, and act. There are quantifiable Levels of Autonomy that can be achieved by tuning different portions of the Observe-Orient-Decide-Act loop to provide flexibility and control. This approach is tabulated for multiple domains such as spacecraft and aerial vehicles. Examining SHM through a Systems Thinking lens helps us understand its stocks and flows, loops, and delays. Systems thinking, and modeling, is a useful way to understand change and complexity of systems of many types. There are certain archetypes that underlie well-known autonomy architectures. And there often are leverage points - best places to intervene in a system - that can resolve or mitigate some fundamental challenges in the design and deployment of autonomous systems. I identify these levers and present the ones that have been successfully used in NASA missions.

Systems Thinking↗

NASA NTRS2015

TTEthernet for Integrated Spacecraft Networks

Aerospace projects have traditionally employed federated avionics architectures, in which each computer system is designed to perform one specific function (e.g. navigation). There are obvious downsides to this approach, including excessive weight (from so much computing hardware), and inefficient processor utilization (since modern processors are capable of performing multiple tasks). There has therefore been a push for integrated modular avionics (IMA), in which common computing platforms can be leveraged for different purposes. This consolidation of multiple vehicle functions to shared computing platforms can significantly reduce spacecraft cost, weight, and design complexity. However, the application of IMA principles introduces significant challenges, as the data network must accommodate traffic of mixed criticality and performance levels - potentially all related to the same shared computer hardware. Because individual network technologies are rarely so competent, the development of truly integrated network architectures often proves unreasonable. Several different types of networks are utilized - each suited to support a specific vehicle function. Critical functions are typically driven by precise timing loops, requiring networks with strict guarantees regarding message latency (i.e. determinism) and fault-tolerance. Alternatively, non-critical systems generally employ data networks prioritizing flexibility and high performance over reliable operation. Switched Ethernet has seen widespread success filling this role in terrestrial applications. Its high speed, flexibility, and the availability of inexpensive commercial off-the-shelf (COTS) components make it desirable for inclusion in spacecraft platforms. Basic Ethernet configurations have been incorporated into several preexisting aerospace projects, including both the Space Shuttle and International Space Station (ISS). However, classical switched Ethernet cannot provide the high level of network determinism required by real-time spacecraft applications. Even with modern advancements, the uncoordinated (i.e. event-driven) nature of Ethernet communication unavoidably leads to message contention within network switches. The arbitration process used to resolve such conflicts introduces variation in the time it takes for messages to be forwarded. TTEthernet1 introduces decentralized clock synchronization to switched Ethernet, enabling message transmission according to a time-triggered (TT) paradigm. A network planning tool is used to allocate each device a finite amount of time in which it may transmit a frame. Each time slot is repeated sequentially to form a periodic communication schedule that is then loaded onto each TTEthernet device (e.g. switches and end systems). Each network participant references the synchronized time in order to dispatch messages at predetermined instances. This schedule guarantees that no contention exists between time-triggered Ethernet frames in the network switches, therefore eliminating the need for arbitration (and the timing variation it causes). Besides time-triggered messaging, TTEthernet networks may provide two additional traffic classes to support communication of different criticality levels. In the rate-constrained (RC) traffic class, the frame payload size and rate of transmission along each communication channel are limited to predetermined maximums. The network switches can therefore be configured to accommodate the known worst-case traffic pattern, and buffer overflows can be eliminated. The best-effort (BE) traffic class behaves akin to classical Ethernet. No guarantees are provided regarding transmission latency or successful message delivery. TTEthernet coordinates transmission of all three traffic classes over the same physical connections, therefore accommodating the full spectrum of traffic criticality levels required in IMA architectures. Common computing platforms (e.g. LRUs) can share networking resources in such a way that failures in non-critical systems (using BE or RC communication modes) cannot impact flight-critical functions (using TT communication). Furthermore, TTEthernet hardware (e.g. switches, cabling) can be shared by both TTEthernet and classical Ethernet traffic.

Loveless, Andrew↗

NASA NTRS2005

Robotic and Human-Tended Collaborative Drilling Automation for Subsurface Exploration

Future in-situ lunar/martian resource utilization and characterization, as well as the scientific search for life on Mars, will require access to the subsurface and hence drilling. Drilling on Earth is hard - an art form more than an engineering discipline. Human operators listen and feel drill string vibrations coming from kilometers underground. Abundant mass and energy make it possible for terrestrial drilling to employ brute-force approaches to failure recovery and system performance issues. Space drilling will require intelligent and autonomous systems for robotic exploration and to support human exploration. Eventual in-situ resource utilization will require deep drilling with probable human-tended operation of large-bore drills, but initial lunar subsurface exploration and near-term ISRU will be accomplished with lightweight, rover-deployable or standalone drills capable of penetrating a few tens of meters in depth. These lightweight exploration drills have a direct counterpart in terrestrial prospecting and ore-body location, and will be designed to operate either human-tended or automated. NASA and industry now are acquiring experience in developing and building low-mass automated planetary prototype drills to design and build a pre-flight lunar prototype targeted for 2011-12 flight opportunities. A successful system will include development of drilling hardware, and automated control software to operate it safely and effectively. This includes control of the drilling hardware, state estimation of both the hardware and the lithography being drilled and state of the hole, and potentially planning and scheduling software suitable for uncertain situations such as drilling. Given that Humans on the Moon or Mars are unlikely to be able to spend protracted EVA periods at a drill site, both human-tended and robotic access to planetary subsurfaces will require some degree of standalone, autonomous drilling capability. Human-robotic coordination will be important, either between a robotic drill and humans on Earth, or a human-tended drill and its visiting crew. The Mars Analog Rio Tinto Experiment (MARTE) is a current project that studies and simulates the remote science operations between an automated drill in Spain and a distant, distributed human science team. The Drilling Automation for Mars Exploration (DAME) project, by contrast: is developing and testing standalone automation at a lunar/martian impact crater analog site in Arctic Canada. The drill hardware in both projects is a hardened, evolved version of the Advanced Deep Drill (ADD) developed by Honeybee Robotics for the Mars Subsurface Program. The current ADD is capable of 20m, and the DAME project is developing diagnostic and executive software for hands-off surface operations of the evolved version of this drill. The current drill automation architecture being developed by NASA and tested in 2004-06 at analog sites in the Arctic and Spain will add downhole diagnosis of different strata, bit wear detection, and dynamic replanning capabilities when unexpected failures or drilling conditions are discovered in conjunction with simulated mission operations and remote science planning. The most important determinant of future 1unar and martian drilling automation and staffing requirements will be the actual performance of automated prototype drilling hardware systems in field trials in simulated mission operations. It is difficult to accurately predict the level of automation and human interaction that will be needed for a lunar-deployed drill without first having extensive experience with the robotic control of prototype drill systems under realistic analog field conditions. Drill-specific failure modes and software design flaws will become most apparent at this stage. DAME will develop and test drill automation software and hardware under stressful operating conditions during several planned field campaigns. Initial results from summer 2004 tests show seven identifi distinct failure modes of the drill: cuttings-removal issues with low-power drilling into permafrost, and successful steps at executive control and initial automation.

Glass, Brian↗

NASA NTRS2000

Autonomy Architectures for a Constellation of Spacecraft

Until the past few years, missions typically involved fairly large expensive spacecraft. Such missions have primarily favored using older proven technologies over more recently developed ones, and humans controlled spacecraft by manually generating detailed command sequences with low-level tools and then transmitting the sequences for subsequent execution on a spacecraft controller. This approach toward controlling a spacecraft has worked spectacularly on previous missions, but it has limitations deriving from communications restrictions - scheduling time to communicate with a particular spacecraft involves competing with other projects due to the limited number of deep space network antennae. This implies that a spacecraft can spend a long time just waiting whenever a command sequence fails. This is one reason why the New Millennium program has an objective to migrate parts of mission control tasks onboard a spacecraft to reduce wait time by making spacecraft more robust. The migrated software is called a "remote agent" and has 4 components: a mission manager to generate the high level goals, a planner/scheduler to turn goals into activities while reasoning about future expected situations, an executive/diagnostics engine to initiate and maintain activities while interpreting sensed events by reasoning about past and present situations, and a conventional real-time subsystem to interface with the spacecraft to implement an activity's primitive actions. In addition to needing remote planning and execution for isolated spacecraft, a trend toward multiple-spacecraft missions points to the need for remote distributed planning and execution. The past few years have seen missions with growing numbers of probes. Pathfinder has its rover (Sojourner), Cassini has its lander (Huygens), and the New Millenium Deep Space 3 (DS3) proposal involves a constellation of 3 spacecraft for interferometric mapping. This trend is expected to continue to progressively larger fleets. For example, one mission proposed to succeed DS3 would have 18 spacecraft flying in formation in order to detect earth-sized planets orbiting other stars. A proposed magnetospheric constellation would involve 5 to 500 spacecraft in Earth orbit to measure global phenomena within the magnetosphere. This work describes and compares three autonomy architectures for a system that continuously plans to control a fleet of spacecraft using collective mission goals instead of goals or command sequences for each spacecraft. A fleet of self-commanding spacecraft would autonomously coordinate itself to satisfy high level science and engineering goals in a changing partially-understood environment making feasible the operation of tens or even a hundred spacecraft (such as for interferometry or plasma physics missions). The easiest way to adapt autonomous spacecraft research to controlling constellations involves treating the constellation as a single spacecraft. Here one spacecraft directly controls the others as if they were connected. The controlling "master" spacecraft performs all autonomy reasoning, and the slaves only have real-time subsystems to execute the master's commands and transmit local telemetry/observations. The executive/diagnostics module starts actions and the master's real-time subsystem controls the action either locally or remotely through a slave. While the master/slave approach benefits from conceptual simplicity, it relies on an assumption that the master spacecraft's executive can continuously monitor the slaves' real-time subsystems, and this relies on high-bandwidth highly-reliable communications. Since unintended results occur fairly rarely, one way to relax the bandwidth requirements involves only monitoring unexpected events in spacecraft. Unfortunately, this disables the ability to monitor for unexpected events between spacecraft and leads to a host of coordination problems among the slaves. Also, failures in the communications system can result in losing slaves. The other two architectures improve robustness while reducing communications by progressively distributing more of the other three remote agent components across the constellation. In a teamwork architecture, all spacecraft have executives and real-time subsystems - only the leader has the planner/scheduler and mission manager. Finally, distributing all remote agent components leads to a peer-to-peer approach toward constellation control.

Barrett, Anthony↗

NASA NTRS2020

Artificial Gravity in Mars Orbit for Crew Acclimation

NASA’s current baseline plan for a crewed Mars mission anticipates a transit time of up to three hundred days in microgravity and 3-14 days on the Martian surface for gravity acclimation before the crew can safely perform their first Extra-Vehicular Activity (EVA). While there are multiple options for how initial surface operations will be performed, all current designs involve acclimation on the surface, and the impacts on the mission schedule, required supplies, and crew lander systems are significant. This paper proposes an alternative option utilizing artificial gravity, which offers benefits in terms of mission scope, mass savings, crew health, and long-term strategic vision. By moving the acclimation requirement to the orbiting habitat’s existing systems, rather than adding redundant systems to the lander, the Mars Descent Vehicle (MDV) can be a much smaller, simpler, and lighter design. Rather than the lander being designed to support crew for days, it would be mere hours. While ambitious, the concept of pre-acclimation in orbit can be not only safe and feasible, but done with fairly minimal changes to the planned architecture and overall mass requirements. The data used draws on decades of established research and demonstrates how this capability can be not only used for pre-acclimation, but also to support crew during early orbital-only missions, surface abort contingency scenarios, return-to-orbit abort scenarios, and as an early proof of capability into larger and more ambitious artificial gravity designs needed for extended exploration missions in the future.

Rowe, Justin↗

NASA NTRS2001

High Speed PC Based Data Acquisition and Instrumentation for Measurement of Simulated Low Earth Orbit Thermally Induced Disturbances

The Hubble Space Telescope (HST) Disturbance Verification Test (DVT) was conducted to characterize responses of the Observatory's new set of rigid solar array's (SA3) to thermally induced 'creak' or stiction releases. The data acquired in the DVT were used in verification of the HST Pointing Control System on-orbit performance, post-Servicing Mission 3B (SM3B). The test simulated the on-orbit environment on a deployed SA3 flight wing. Instrumentation for this test required pretest simulations in order to select the correct sensitivities. Vacuum compatible, highly accurate accelerometers and force gages were used for this test. The complexity of the test, as well as a short planning schedule, required a data acquisition system that was easy to configure, highly flexible, and extremely robust. A PC Windows oriented data acquisition system meets these requirements, allowing the test engineers to minimize the time required to plan and perform complex environmental test. The SA3 DVT provided a direct practical and complex demonstration of the versatility that PC based data acquisition systems provide. Two PC based data acquisition systems were assembled to acquire, process, distribute, and provide real time processing for several types of transducers used in the SA3 DVT. A high sample rate digital tape recorder was used to archive the sensor signals. The two systems provided multi-channel hardware and software architecture and were selected based on the test requirements. How these systems acquire and processes multiple data rates from different transducer types is discussed, along with the system hardware and software architecture.

Sills, Joel W., Jr.↗

NASA NTRS2011

FPA Depot - Web Application

Lines of code (LOC) analysis is one of the methods used to measure programmer productivity and estimate schedules of programming projects. The Launch Control System (LCS) had previously used this method to estimate the amount of work and to plan development efforts. The disadvantage of using LOC as a measure of effort is that one can only measure 30% to 35% of the total effort of software projects involves coding [8]. In the application, instead of using the LOC we are using function point for a better estimation of hours in each software to develop. Because of these disadvantages, Jamie Szafran of the System Software Branch of Control And Data Systems (NE-C3) at Kennedy Space Canter developed a web application called Function Point Analysis (FPA) Depot. The objective of this web application is that the LCS software architecture team can use the data to more accurately estimate the effort required to implement customer requirements. This paper describes the evolution of the domain model used for function point analysis as project managers continually strive to generate more accurate estimates.

Avila, Edwin M. Martinez↗