Results for “scenario” — Page 25

NASA NTRS2015

SimSup's Loop: A Control Theory Approach to Spacecraft Operator Training

Immersive simulation is a staple of training for many complex system operators, including astronauts and ground operators of spacecraft. However, while much has been written about simulators, simulation facilities, and operator certification programs, the topic of how one develops simulation scenarios to train a spacecraft operator is relatively understated in the literature. In this paper, an approach is presented for using control theory as the basis for developing the immersive simulation scenarios for a spacecraft operator training program. The operator is effectively modeled as a high level controller of lower level hardware and software control loops that affect a select set of system state variables. Simulation scenarios are derived from a STAMP-based hazard analysis of the operator's high and low level control loops. The immersive simulation aspect of the overall training program is characterized by selecting a set of scenarios that expose the operator to the various inadequate control actions that stem from control flaws and inadequate control executions in the different sections of the typical control loop. Results from the application of this approach to the Lunar Atmosphere and Dust Environment Explorer (LADEE) mission are provided through an analysis of the simulation scenarios used for operator training and the actual anomalies that occurred during the mission. The simulation scenarios and inflight anomalies are mapped to specific control flaws and inadequate control executions in the different sections of the typical control loop to illustrate the characteristics of anomalies arising from the different sections of the typical control loop (and why it is important for operators to have exposure to these characteristics). Additionally, similarities between the simulation scenarios and inflight anomalies are highlighted to make the case that the simulation scenarios prepared the operators for the mission.

LADEE↗

NASA NTRS2021

A Ground-Delay-Based Approach to Reduce Impedance-Based Airspace Complexity

This paper introduces a ground delay based traffic management approach to reduce the impedance based airspace complexity for a given scenario. The preliminary work presented here extends our prior research on developing an impedance based complexity metric for unmanned aircraft system traffic scenario classification. Impedance based metric was evaluated for 1045 randomly-generated scenarios. Scenarios with overall impedance above a certain threshold were declared as no-go. A ground delay approach was developed to be applied to the rest of the scenarios so as to remediate any scenarios with small areas of high impedance on their impedance maps. A sample application is shown for a scenario with sixty flights. The final paper will include detailed trade-offs between overall accrued system delay and the delay tolerance for each aircraft. A sample application to a potential Urban Air Mobility traffic scenario will also be included in the final paper.

Vishwanath Bulusu↗

NASA NTRS2021

A Ground-Delay-Based Approach to Reduce Impedance-Based Airspace Complexity

This paper introduces a ground-delay-based traffic management approach to reduce the impedance-based airspace complexity for a given scenario. This work extends our prior research on developing an impedance-based complexity metric for unmanned aircraft system traffic scenario classification. Impedance-based metric was evaluated for 1045 randomly generated scenarios. Scenarios with overall impedance above a certain threshold were declared as not feasible. A ground-delay-based approach was developed to be applied to the rest of the scenarios so as to remediate any scenarios with small areas of high impedance on their impedance maps. A sample application is shown for a scenario with sixty flights. The detailed trade-offs between overall accrued system delay, the number of delayed flights, the total number of conflicts and the highest impedance observed as a function of the delay tolerance for each aircraft are provided. Potential applications to Urban Air Mobility traffic scenarios are also discussed.

ground-delay based traffic management↗

NASA NTRS1997

Free Flight and Self-Separation from the Flight Deck Perspective

The concept of "free flight", while still being developed, is intended to emphasize more, flexibility for operators in the National Airspace System (NAS) by providing more separation responsibility to pilots, New technologies, procedures, and concepts have been suggested by the aviation community to enable this task; however, much work needs to be accomplished to help define and evaluate the concept feasibility. The purpose of this simulation was to begin examining some of the communication and procedural issues associated with self-separation in the enroute environment. A simulation demonstration was conducted in the Boeing 747-400 simulator at NASA Ames Research Center. Commercial pilots (from a U.S. domestic carrier) current on the B747-400 aircraft were the participants. Ten flight crews (10 captains, 10 first officers) flew in the Denver enroute airspace environment. A new alerting logic designed to allow for airborne self-separation was created for this demonstration. This logic assumes automatic dependent surveillance broadcast (ADS-B) capability and represented aircraft up to 120 nautical miles on the display. The new flight deck display features were designed and incorporated on the existing navigational display in the simulator to allow for increased traffic and maneuvering information to the flight crew. New tools were also provided to allow the crews to assess conflicts and potential maneuvers before implementing them. Each of the flight crews flew eight different scenarios in the Denver enroute airspace. The scenarios included eight to ten other aircraft, and each scenario was created with the intent of having one of the other aircraft become an operational conflict for our simulator aircraft. Different types of conflict geometries were represented across the eight scenarios. Also, some scenarios allowed for more time to detect a potential clearance, while others allowed for less time for'detection. Additionally, the crews were asked to a ply the Visual Flight Rules (VFR) right of way rules when determining who should maneuver in a conflict situation; therefore, the scenarios were designed to test different applications of those recommendations, Data analyses include an evaluation of crew procedures and communication. The application of the VFR right-of-way rules are being explored. Timing variables are being examined to determine potential efficiency differences between scenarios and conflict types. Proximity of aircraft will be assessed as one indication of the operational safety. The intent of these evaluations is to help provide definitions and guidelines of negotiation procedures in a self-separation environment assuming automated data link technology (ADS-B). Also, definitions of likely flight crew maneuvers and application to current VFR right-of-way rules may be obtained, along with guidelines for negotiation procedures between flight crews.

Lozito, Sandra↗

NASA NTRS2004

Transitioning from Software Requirements Models to Design Models

The Scenario Creation and Simulation Process (SCASP) includes the following steps: 1) Write Requirements; 2) Write Use Cases; 3) Prioritize Use Cases; 4) Write Nominal Scenarios; 5) Identify Relationships; 6) Refine/Generalize Scenarios; 7) Transform to State Machines. SCASP provides thorough simulation of use cases before design/implementation, resulting in: 1) Reduced cost; 2) Fewer misunderstandings; 3) Reuse of executable form of use cases. SCASP gives systematic guidelines on how to 1) Separate concerns in use case descriptions; 2) Elicit non-nominal scenarios (alternatives, exceptions, concurrent scenarios, etc.); 3) Transform those scenarios automatically into a set of concurrent state machines; 4) Execute those state machines, i.e., scenario simulation.

Whittle, Jon↗

NASA NTRS2007

Reducing a Knowledge-Base Search Space When Data Are Missing

This software addresses the problem of how to efficiently execute a knowledge base in the presence of missing data. Computationally, this is an exponentially expensive operation that without heuristics generates a search space of 1 + 2n possible scenarios, where n is the number of rules in the knowledge base. Even for a knowledge base of the most modest size, say 16 rules, it would produce 65,537 possible scenarios. The purpose of this software is to reduce the complexity of this operation to a more manageable size. The problem that this system solves is to develop an automated approach that can reason in the presence of missing data. This is a meta-reasoning capability that repeatedly calls a diagnostic engine/model to provide prognoses and prognosis tracking. In the big picture, the scenario generator takes as its input the current state of a system, including probabilistic information from Data Forecasting. Using model-based reasoning techniques, it returns an ordered list of fault scenarios that could be generated from the current state, i.e., the plausible future failure modes of the system as it presently stands. The scenario generator models a Potential Fault Scenario (PFS) as a black box, the input of which is a set of states tagged with priorities and the output of which is one or more potential fault scenarios tagged by a confidence factor. The results from the system are used by a model-based diagnostician to predict the future health of the monitored system.

James, Mark↗

NASA NTRS2019

Communication Bandwidth Considerations for Exploration Medical Care During Space Missions

Destinations beyond low Earth orbit, especially Mars, have several important constraints, including limited resupply, limited to no possibility of medical evacuation, and delayed communication with ground support teams. Therefore, medical care is driven towards greater autonomy and necessitates a medical system that supports this paradigm, including the potential for high medical data transfer rates in order to share medical information and coordinate care with the ground in an intermittent fashion as communication allows. The medical data transfer needs for a Martian exploration mission were estimated by defining two medical scenarios that would require high data rate communications between the spacecraft and Earth. One medical scenario involves a case of hydronephrosis (outflow obstruction of the kidney) that evolves into pyelonephritis (kidney infection), then urosepsis (systemic infection originating from the kidney), due to obstruction by a kidney stone. A second medical scenario involved the death of a crewmember’s child back on Earth that requires behavioral health care. For each of these scenarios, a data communications timeline was created following the medical care described by the scenario. From these timelines, total medical data transfers and burst transmission rates were estimated. Total data transferred from the vehicle-to-ground were estimated to be 94 gigabytes (GB) and 835 GB for the hydronephrosis and behavioral health scenarios, respectively. Data burst rates were estimated to be 7.7 megabytes per second (MB/s) and 15 MB/s for the hydronephrosis and behavioral health scenarios, respectively. Even though any crewed Mars mission should be capable of functioning autonomously, as long as the possibility of communication between Earth and Mars exists, Earth-based subject matter experts will be relied upon to augment mission medical capability. Therefore, setting an upper boundary limit for medical communication rates can help factor medical system needs into total vehicle communication requirements.

Krihak, Michael↗

NASA NTRSDate not supplied

Clinical Decision Support - Concepts of Operation

We are entering a new era in space exploration to return to the moon and explore Mars. Crew members operating independently during long duration space exploration missions will require a clinical decision support system (CDSS) to increase autonomy by augmenting their knowledge, skills and abilities in different scenarios. Significant changes to in-flight and habitat medical care due to constraints on mass, volume, power, crew time and medical evacuation capabilities are needed to increase crew autonomy and self-reliance in decision making and task performance. The Exploration Medical Capability (ExMC) Element of the Human Research Program (HRP) pushes the boundary of space medical systems to advance the care of astronauts on future exploration missions beyond low Earth orbit by identifying and testing next-generation medical care and crew health maintenance technologies. Clinical decision support (CDS) presents knowledge and data in a context aware manner to augment a crew members’ knowledge, skills and abilities during the process of observation, orientation, decisions and action. A comprehensive crew health and performance CDSS is required to augment crew capability and will be used in different scenarios for several reasons. In general, the CDSS’s role is to assist the crew in prevention, detection, diagnosis and treatment of crew health and performance related conditions that may arise in exploration spaceflight. For example, CDSS would assist a high acuity scenario such as a heart attack by supplying clear instructions, vital signs and treatment reminders. A lower severity scenario such as kidney stone risk could interface to vehicle systems and display more complex predictive data during a diagnosis. A CDSS needs to contribute to successful missions by maintaining a high performing crew who can potentially exhibit countless medical conditions related to derangements from the space environment (sleep, cognition, nutrition and exercise) as well as conditions intrinsic to humans anywhere. While supporting the crew’s ability to make sound clinical decisions is desirable in any mission, it is essential for exploration missions with significant communication delays, no evacuation capability, and extended exposure to the flight environment. Such missions correspond with medical Level of Care V (LOC V), the highest level specified in NASA-STD-3001. The project focuses on CDS implementation research to derive requirements for LOC V, where the need for increased autonomy results in new practices and the inclusion of non-clinical data, such as vehicle environmental measures and physical exercise results, from other human and vehicle domains and advanced analytics. The CDS project describes how the CDSS is intended to be used by defining concepts of operations (ConOps). The process to derive ConOps focuses on increased autonomy that reduces the likelihood and consequences of accepted medical conditions. These crew health and performance inputs are grouped by common datasets and analysis models. Use cases are derived to research new clinical scenarios, architectural development and workflows. Implementation research is conducted with protypes to inform assumptions and derive requirements. The project also establishes how externally developed analysis and approaches can be added to expand a clinical decision support system and thus highlight how a comprehensive system can be globally developed with collaborators. This presentation will cover example scenarios from the CDS ConOps and the method to derive them. One example scenario will be CDSS alerting an increased kidney stone risk during a mission, with diagnosis and treatment options provided during the intervention.

clinical decision support↗

NASA NTRSDate not supplied

Clinical Decision Support - Concepts of Operation

We are entering a new era in space exploration to return to the moon and explore Mars. Crew members operating independently during long duration space exploration missions will require a clinical decision support system (CDSS) to increase autonomy by augmenting their knowledge, skills and abilities in different scenarios. Significant changes to in-flight and habitat medical care due to constraints on mass, volume, power, crew time and medical evacuation capabilities are needed to increase crew autonomy and self-reliance in decision making and task performance. The Exploration Medical Capability (ExMC) Element of the Human Research Program (HRP) pushes the boundary of space medical systems to advance the care of astronauts on future exploration missions beyond low Earth orbit by identifying and testing next-generation medical care and crew health maintenance technologies. Clinical decision support (CDS) presents knowledge and data in a context aware manner to augment a crew members’ knowledge, skills and abilities during the process of observation, orientation, decisions and action. A comprehensive crew health and performance CDSS is required to augment crew capability and will be used in different scenarios for several reasons. In general, the CDSS’s role is to assist the crew in prevention, detection, diagnosis and treatment of crew health and performance related conditions that may arise in exploration spaceflight. For example, CDSS would assist a high acuity scenario such as a heart attack by supplying clear instructions, vital signs and treatment reminders. A lower severity scenario such as kidney stone risk could interface to vehicle systems and display more complex predictive data during a diagnosis. A CDSS needs to contribute to successful missions by maintaining a high performing crew who can potentially exhibit countless medical conditions related to derangements from the space environment (sleep, cognition, nutrition and exercise) as well as conditions intrinsic to humans anywhere. While supporting the crew’s ability to make sound clinical decisions is desirable in any mission, it is essential for exploration missions with significant communication delays, no evacuation capability, and extended exposure to the flight environment. Such missions correspond with medical Level of Care V (LOC V), the highest level specified in NASA-STD-3001. The project focuses on CDS implementation research to derive requirements for LOC V, where the need for increased autonomy results in new practices and the inclusion of non-clinical data, such as vehicle environmental measures and physical exercise results, from other human and vehicle domains and advanced analytics. The CDS project describes how the CDSS is intended to be used by defining concepts of operations (ConOps). The process to derive ConOps focuses on increased autonomy that reduces the likelihood and consequences of accepted medical conditions. These crew health and performance inputs are grouped by common datasets and analysis models. Use cases are derived to research new clinical scenarios, architectural development and workflows. Implementation research is conducted with protypes to inform assumptions and derive requirements. The project also establishes how externally developed analysis and approaches can be added to expand a clinical decision support system and thus highlight how a comprehensive system can be globally developed with collaborators. This presentation will cover example scenarios from the CDS ConOps and the method to derive them. One example scenario will be CDSS alerting an increased kidney stone risk during a mission, with diagnosis and treatment options provided during the intervention.

clinical decision support↗

NASA NTRSDate not supplied

Model Performance in Simulating the Mid-Holocene Green Sahara

The Green Sahara Period, spanning about 11,500 to 5,000 years ago, offers an opportunity to test the ability of climate models to simulate large-scale changes in northern African climate through the strengthening of the West African Monsoon. In this study, we evaluate the performance of four models in simulating the mid-Holocene (6,000 BP), namely – EC-Earth, iCESM, CCSM4-Toronto, and the GISS ModelE2.1-G. Two scenarios are considered for each model – a standard PMIP scenario simulated with the mid-Holocene orbital parameters and greenhouse gas concentrations with vegetation prescribed to pre-industrial conditions, as well as a Green-Sahara scenario which additionally considers factors such as enhanced vegetation, reduced dust, presence of lakes, and land and soil feedbacks. All mid-Holocene scenarios capture an increase in monsoonal precipitation in northern Africa. However, a comparison of the two mid-Holocene scenarios reveals significantly higher precipitation in northern Africa for all the Green-Sahara scenarios relative to the PMIP scenarios – an observation consistent across all models. Accompanied by a strengthened Saharan Heat Low, these changes in the West African Monsoon are also linked to polar amplification, a stronger Indian Summer Monsoon and alterations to the Walker circulation. Model results are in agreement with pollen-based SAT records, multi-proxy SST records and African lake level records. This comparison indicates that a realistic simulation of the mid-Holocene Green Sahara requires consideration of multiple factors in addition to orbital and greenhouse gas forcings.

Green Sahara Period↗

NASA NTRSDate not supplied

Usability Evaluation of Fleet Management Interface for High Density Vertiplex Environments

To meet the rising demand for an Advanced Air Mobility (i.e. urban and rural unmanned aircraft systems) ecosystem, NASA Aeronautics Research Mission Directorate (ARMD) is hosting a series of simulations and flight tests under the High Density Vertiplex sub-project (HDV). HDV aims to develop an integrated automation architecture to support terminal area flight operations. The HDV simulations and flight tests address safety, integration, and operational challenges, while integrated systems and software demonstrate design readiness, robustness, and interoperability. During the initial HDV simulation in 2021, a prototype traffic management tool developed by NASA called Fleet Management Interface (FMI) was tested. FMI was designed to introduce an advanced level of human-automation interaction to aid both Ground Control Station Operators (GCSOs) and Fleet Managers (FMs) in remotely managing flights under their ownership. In a human-in-the-loop simulation, a usability study was conducted with FMI to identify optimal approaches for displaying information for human operators using subjective measures of usability, workload, situation awareness, risk, and trust, along with qualitative feedback. This study consisted of task analysis in which GCSO and FM subjects used an Urban Air Mobility (UAM) environment to develop and execute a plan for two different traffic scenarios of remotely controlled vehicles. In each scenario, a controlled vehicle completed a takeoff, active flight, and landing sequence while automated traffic flew in the background at a rate of 20 operations per hour. In the first scenario, the controlled vehicle flew a nominal route with takeoff and landing at the same vertiport. In the second scenario, the controlled vehicle started on the nominal route, then diverted to an unplanned location mid-flight. Results showed that self-reported performance, usability, trust, and situation awareness ratings of FMI were moderately to strongly high. There were small differences between scenarios, with Scenario 2 being perceived as more unstable, complex, variable, risky, and potentially harmful than Scenario 1. Furthermore, participants described improvements that could be made to create a better user experience. For example, users would like greater configurability of the interface based on their personal information requirements, and they would like the opportunity to review routes before assigning them. The results from this study will inform future development of the FMI with the end goal of creating a reference automation tool for airspace management procedures in AAM. The FMI could be introduced as a potential way to reduce dependency on traditional air navigation services through increased automation in high density vertiplex environments.

vertiplex↗

NASA NTRSDate not supplied

Usability Evaluation of Fleet Management Interface for High Density Vertiplex Environments

To meet the rising demand for an Advanced Air Mobility (AAM) (i.e. urban and rural unmanned aircraft systems) ecosystem, the NASA Aeronautics Research Mission Directorate (ARMD) is hosting a series of simulations and flight tests under the High Density Vertiplex sub-project (HDV) to prototype and study the effectiveness AAM capabilities under various operational contexts. HDV aims to develop an integrated automation architecture to support terminal area flight operations. The HDV simulations and flight tests address safety, integration, and operational challenges, while integrated systems and software demonstrate design readiness, robustness, and interoperability. During the initial HDV simulation in 2021, a prototype traffic management tool developed by NASA called the Fleet Management Interface (FMI) was tested. FMI was designed to introduce an advanced level of human-automation interaction to aid both Ground Control Station Operators (GCSOs) and Fleet Managers (FMs) in remotely managing flights under their ownership. In a human-in-the-loop simulation, a usability study was conducted with the FMI to identify optimal approaches for displaying information to human operators using subjective measures of usability, workload, situation awareness, risk, and trust, along with qualitative feedback. This study consisted of task analysis in which GCSO and FM subjects used an Urban Air Mobility (UAM) environment to develop and execute a plan for two different traffic scenarios of remotely controlled vehicles. In each scenario, a remotely controlled vehicle completed a takeoff, active flight, and landing sequence while simulated traffic flew in the background at a rate of 20 operations per hour. In the first scenario, the controlled vehicle flew a nominal route with takeoff and landing at the same vertiport. In the second scenario, the controlled vehicle started on the nominal route, then diverted to an unplanned location mid-flight. Results showed that self- reported performance, usability, trust, and situation awareness ratings of FMI were moderately to strongly high. There were small differences between scenarios, with Scenario 2 being perceived as more unstable, complex, variable, risky, and potentially harmful than Scenario 1. Furthermore, participants described improvements that could be made to create a better user experience. For example, users suggested customizable interfaces to accommodate information display preferences, and the ability to review routes before assigning them. The results from this study will inform future development of the FMI with the end goal of creating a reference automation tool for airspace management procedures in AAM. The FMI could serve to reduce dependency on traditional air navigation services through increased automation in high density vertiplex environments.

Fleet manager↗

NASA NTRS1974

Energy impact of short-haul STOL systems

An analysis has been made to evaluate the impact on fuel requirements of a segregated short-haul system. A comparison has been made between two alternate scenarios: one with STOL, and the other without STOL. For the New York to Washington, D.C. city pair the results show: (1) the modal efficiency approach, while indicating the with STOL scenario requires more fuel than the without STOL scenario, is of questionable validity because it does not account for various effects which exist in realistic scenarios; (2) evaluation of fuel requirements based on more detailed modeling indicates that while a STOL scenario requires more fuel than without STOL when an idealized CTOL system is postulated, the STOL scenario requires less fuel than without STOL when the CTOL system has even moderate delays. These results are due to a combination of effects: the closer and more convenient locations of STOL ports to the traveler, congestion at the CTOL airports, and the impact of the through passenger traffic. Sensitivity of results to STOL aircraft block fuel and to CTOL congestion delays are considered.

Stewart, E. C.↗

NASA NTRS1976

Advanced space system concepts and their orbital support needs (1980 - 2000). Volume 4: Detailed data. Part 2: Program plans and common support needs (a study of the commonality of space vehicle applications to future national needs

The methodology of alternate world future scenarios is utilized for selecting a plausible, though not advocated, set of future scenarios each of which results in a program plan appropriate for the respective environment. Each such program plan gives rise to different building block and technology requirements, which are analyzed for common need between the NASA and the DoD for each of the alternate world scenarios. An essentially invariant set of system, building block, and technology development plans is presented at the conclusion, intended to allow protection of most of the options for system concepts regardless of what the actual future world environment turns out to be. Thus, building block and technology needs are derived which support: (1) each specific world scenario; (2) all the world scenarios identified in this study; or (3) generalized scenarios applicable to almost any future environment. The output included in this volume consists of the building blocks, i.e.: transportation vehicles, orbital support vehicles, and orbital support facilities; the technology required to support the program plans; identification of their features which could support the DoD and NASA in common; and a complete discussion of the planning methodology.

Bekey, I.↗

NASA NTRS1988

Space-based laser-powered orbital transfer vehicle (Project SLICK)

A conceptual design study of a laser-powered orbital transfer vehicle (LOTV) is presented. The LOTV, nicknamed SLICK (Space Laser Interorbital Cargo Kite), will be utilized for the transfer of 16000 kg of cargo between Low Earth Orbit (LEO) and either Geosynchronous Earth Orbit (GEO) or Low Lunar Orbit (LLO). This design concentrates primarily on the LEO/GEO scenario, which will have typical LEO-to-GEO trip time of 6 days and two return versions. One version uses an all propulsive return while the other utilizes a ballute aerobrake for the return trip. Furthermore, three return cargo options of 16000 kg, 5000 kg (standard option), and 1600 kg are considered for this scenario. The LEO/LLO scenario uses only a standard, aerobraked version. The basic concept behind the LOTV is that the power for the propulsion system is supplied by a source separate from the LOTV itself. For the LEO/GEO scenario the LOTV utilizes a direct solar-pumped iodide laser and possibly two relay stations, all orbiting at an altitude of one Earth radius and zero inclination. An additional nuclear-powered laser is placed on the Moon for the LEO/LLO scenario. The propulsion system of the LOTV consists of a single engine fueled with liquid hydrogen. The laser beam is captured and directed by a four mirror optical system through a window in the thrust chamber of the engine. There, seven plasmas are created to convert the laser beam energy into thermal energy at an efficiency of at least 50 percent. For the LEO/LLO scenario the laser propulsion is supplemented by LH2/LOX chemical thrusters.

Source record↗

NASA NTRS1986

DIOGENES: Expert system for extraction of data system requirements

AA The initial operations concept expresses information about system objectives, and defines the system users, system interfaces, and operational performance constraints. We have developed a prototype expert system which has established the feasibility of automating a scenario-driven methodology for deriving top-level specifications and preliminary designs for user data systems. This scenario-driven methodology uses an initial design, an initial operations concept, and user scenarios as the starting point for system definition. The top-level initial design is a functional description of the system in the form of an annotated data flow diagram. The initial operations concept expresses informationabout system objectives, and defines the system users, system interfaces, and operational performance constraints. The user scenarios are detailed time-lined descriptions of user activities, developed by prospective end users. These scenarios, along with the initial design and operations concept, are analyzed and iterated by the expert system to form a consistent set. The resulting User Scenario-Operation Set plays a key role in the development of requirements and system tests.

Hobbs, Robert W.↗

NASA NTRS1998

The Sound Parameter Effect in Metal-Rich Globular Clusters

Recent Hubble Space Telescope observations have found that the horizontal branches (HBs) in the metal-rich globular clusters NGC 6388 and NGC 6441 slope upward with decreasing B - V. Such a slope is not predicted by canonical HB models and cannot be produced by either a greater cluster age or enhanced mass loss along the red giant branch (RGB). The peculiar HB morphology in these clusters may provide an important clue for understanding the second-parameter effect. We have carried out extensive evolutionary calculations and numerical simulations in order to explore three noncanonical scenarios for explaining the sloped HBs in NGC 6388 and NGC 6441: (1) a high cluster helium abundance scenario, in which the HB evolution is characterized by long blue loops; (2) a rotation scenario, in which internal rotation during the RGB phase increases the HB core mass; and (3) a helium-mixing scenario, in which deep mixing on the RGB enhances the envelope helium abundance. All of these scenarios predict sloped HBs with anomalously bright RR Lyrae variables. We compare this prediction with the properties of the two known RR Lyrae variables in NGC 6388. Additional observational tests of these scenarios are suggested.

Hall, D. K↗

NASA NTRS2000

Protocol Architecture Model Report

NASA's Glenn Research Center (GRC) defines and develops advanced technology for high priority national needs in communications technologies for application to aeronautics and space. GRC tasked Computer Networks and Software Inc. (CNS) to examine protocols and architectures for an In-Space Internet Node. CNS has developed a methodology for network reference models to support NASA's four mission areas: Earth Science, Space Science, Human Exploration and Development of Space (REDS), Aerospace Technology. This report applies the methodology to three space Internet-based communications scenarios for future missions. CNS has conceptualized, designed, and developed space Internet-based communications protocols and architectures for each of the independent scenarios. The scenarios are: Scenario 1: Unicast communications between a Low-Earth-Orbit (LEO) spacecraft inspace Internet node and a ground terminal Internet node via a Tracking and Data Rela Satellite (TDRS) transfer; Scenario 2: Unicast communications between a Low-Earth-Orbit (LEO) International Space Station and a ground terminal Internet node via a TDRS transfer; Scenario 3: Multicast Communications (or "Multicasting"), 1 Spacecraft to N Ground Receivers, N Ground Transmitters to 1 Ground Receiver via a Spacecraft.

Dhas, Chris↗