Search NASA⌕ Search

SEARCH · Search NASA

Results for “Team software development”

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 577 records · Page 32

Mars Exploration Rover Operations with the Science Activity Planner

The Science Activity Planner (SAP) is the primary science operations tool for the Mars Exploration Rover mission and NASA's Software of the Year for 2004. SAP utilizes a variety of visualization and planning capabilities to enable the mission operations team to direct the activities of the Spirit and Opportunity rovers. This paper outlines some of the challenging requirements that drove the design of SAP and discusses lessons learned from the development and use of SAP in mission operations.

ground systems↗

Reconfigurable, Intelligently-Adaptive, Communication System, an SDR Platform

The Space Telecommunications Radio System (STRS) provides a common, consistent framework to abstract the application software from the radio platform hardware. STRS aims to reduce the cost and risk of using complex, configurable and reprogrammable radio systems across NASA missions. The NASA Glenn Research Center (GRC) team made a software defined radio (SDR) platform STRS compliant by adding an STRS operating environment and a field programmable gate array (FPGA) wrapper, capable of implementing each of the platforms interfaces, as well as a test waveform to exercise those interfaces. This effort serves to provide a framework toward waveform development onto an STRS compliant platform to support future space communication systems for advanced exploration missions. The use of validated STRS compliant applications provides tested code with extensive documentation to potentially reduce risk, cost and e ort in development of space-deployable SDRs. This paper discusses the advantages of STRS, the integration of STRS onto a Reconfigurable, Intelligently-Adaptive, Communication System (RIACS) SDR platform, and the test waveform and wrapper development e orts. The paper emphasizes the infusion of the STRS Architecture onto the RIACS platform for potential use in next generation flight system SDRs for advanced exploration missions.

space communications↗

Analysis and Review of NASA Earth Science Metadata: How Automation Plays a Role

The Analysis and Review of the Common Metadata Repository (CMR ARC) Team reviews all EOSDIS metadata. The team’s objective is to achieve consistency, correctness, and completeness for all metadata records in the CMR, as well as improve the discoverability of NASA's Earth Science data within the CMR framework. This work is currently being completed at Marshall Space Flight Center. CMR makes a single discovery point possible for NASA's Earth Science data users. The CMR team, in collaboration with three other core metadata teams, contributes to the stewardship of NASA's Earth Science data through a process of continual curation and the ongoing development of the Unified Metadata Model (UMM). A key tool now used in the curation process, referred to as the NASA CMR Dashboard, is an online curation dashboard developed in collaboration with software development company, Element 84. This tool facilitates the review of Earth Science metadata records and subsequent stakeholder collaboration on the resolution of identified issues. A key capability of the new tool is a suite of automated compliance checks written in Python 3.6 that verify the integrity of various metadata elements across multiple standards.

Staton, Patrick↗

Lessons Learned from the Flight Unit Testing of the Near Earth Asteroid Scout Flight System

The Near Earth Asteroid Scout flight mission is set to launch on the maiden voyage of the Space Launch System as a secondary payload. The spacecraft will be jettisoned in cis-lunar space and embark on an ambitious 2.5 year mission to image an asteroid. The spacecraft is uniquely equipped with an 85m2 solar sail as the main propulsion system. The monolithic sail system is designed to package within a 6U volume for launch and then deploy during flight. The NEA Scout team has presented in the past to the International Symposium on Solar Sailing topics related to the engineering development unit and design efforts to achieve flight hardware build. This paper will focus on the lessons learned from building and testing the NEA Scout flight system. Focus will be on the mechanical, software, and electrical interfaces as well as preparation for subsystem environmental tests, including thermal vacuum. Due to the unique design of the spacecraft, the solar sail subsystem was required to be located in the center of the spacecraft. This requirement lead to design challenges such as designing and accommodating critical cable harnesses to run through the center of the sail subsystem, packaging and deployment design of the sail subsystem, and integrated testing efforts through an avionics test bed to verify and validate a complete system architecture.

Lockett, Tiffany Russell↗

Robotic Assembly Activities at NASA Langley Research Center

Over the past several decades, NASA Langley Research Center (LaRC) has developed a suite of hardware and software capabilities for robotic in-space assembly. Specific robots include the Lightweight Surface Manipulation System (LSMS), Tendon-Actuated Lightweight In-Space Manipulator (TALISMAN), NASA Intelligent Jigging and Assembly Robot (NINJAR), Strut Assembly, Manufacturing, Utility & Robotic Aid (SAMURAI), and most recently the Assemblers modular robots. Alongside the hardware, software tools such as the Autonomous Entity Operations Network (AEON) and the Baseline Environment for Autonomous Modeling (BEAM) have been developed to enable communication and simulation respectively. These tools have supported foundational research in single and multi-agent control, sensing and perception, trajectory generation, task allocation, and human-machine teaming. This talk will provide a broad overview of these capabilities and go into detail on recent developments made by the Assemblers project to create modular, reconfigurable robots for autonomous in-space assembly.

John R Cooper↗

Micrometeoroid and Orbital Debris (MMOD) Testing, Ballistic Limit Definition and Risk Assessment of the Exploration Extravehicular Mobility Unit (xEMU)

A well-known hazard associated with exposure to the space environment is the risk of failure due to an impact from a micrometeoroid and orbital debris (MMOD) particle. As NASA prepares to return astronauts to the moon with the Artemis program, the next generation of spacesuit is in development to support future extravehicular activities (EVAs.) An MMOD impact to the spacesuit is of great concern as a large leak could prevent an astronaut from safely reaching an airlock in time resulting in a loss of life. The exploration extravehicular mobility unit (xEMU) must meet MMOD requirements for multiple environments including those in low earth orbit (LEO) as well as the meteoroid and secondary lunar regolith ejecta environments found on the lunar surface. The subject of this paper is an internal xEMU configuration design developed by NASA Johnson Space Center (JSC) personnel. The xEMU shares similarities with the legacy Extravehicular Mobility Unit (EMU) spacesuit that is currently used for ISS EVAs, however differences in the layup (e.g., materials, thicknesses, and layers) of the fabric environmental protection garment (EPG), portable life support system (xPLSS) and helmet required an extensive test program to determine ballistic performance. Over 100 hypervelocity impact (HVI) tests were performed by the NASA/JSC HVIT and White Sands Test Facility (WSTF) teams on the xEMU EPG, xPLSS and helmet to generate ballistic limit equations (BLEs) for MMOD impacts. Additionally, over 50 low speed tests (< 1km/s) were performed by the NASA/JSC HVIT and Southwest Research Institute (SwRI) teams on the xEMU EPG, xPLSS and helmet to generate BLEs for lunar ejecta impacts. Post testing, ballistic limit equations (BLEs) used to define the performance of the various regions on the xEMU spacesuit were developed from a generic set of BLEs. The HVI and low speed testing was performed to establish a physical basis for the equations with the coefficients and exponents of the generic BLEs adjusted to fit the test data. The xEMU BLEs were added to the NASA/JSC software application used for spacecraft MMOD risk assessments (BUMPER-3). A finite element model (FEM) of the xEMU spacesuit, which defines the size and shape of the spacesuit as well as the locations of the various shielding configurations, was created based on a solid model provided by the xEMU program office. Using the FEM file and added xEMU BLEs, BUMPER-3 assessments of the xEMU spacesuit for probability of no penetration (PNP) were performed. For the LEO assessment of a typical ISS EVA, the orbital debris and meteoroids environments were defined using the latest engineering models, ORDEM 3.2 and MEM-3 respectively. The lunar surface assessment again used the MEM-3 engineering model to define the meteoroid environment along with the current released lunar surface ejecta model, NASA SP-8013 (developed during the Apollo Program). The Space Team in the Natural Environments Branch at Marshall Space Flight Center (MSFC) will soon release the new Lunar Meteoroid Ejecta Engineering Model (LMEEM), at which time the xEMU lunar surface EVA will be reassessed. Assessment of the MMOD risk for an 8-hour, 2-person EVA in both LEO and on the lunar surface showed that the xEMU spacesuit meets the program technical requirement of 1 in 2500 failure odds. Similar to the legacy EMU spacesuit, the majority of the MMOD risk (96% of the LEO EVA risk and 99% of the lunar surface EVA risk) is concentrated in regions of xEMU that are comprised primarily of softgoods (arms, legs, and gloves) rather than the hardgoods (xPLSS, hard upper torso and helmet).

Micrometeoroid↗

Application of a Prize Mechanism to Address Data Utilization Challenges at Utilities

The electric industry sector is facing an “explosion” of data from a variety of sources. Electric sector stakeholders need to define how to capitalize on large datasets, both those they create and those from other sources (like data on weather, buildings, electric vehicles, etc.), to improve reliability and resilience and meet the changing system dynamics from renewable integration. For the electricity sector to fully utilize these vast new datasets, it must undergo a transformation in how it manages data quality, storage, and processing. The U.S. Department of Energy (DOE) Office of Electricity (OE) is committed to accelerating research, development, and demonstration of new technologies and tools within the electricity sector to advance reliability, resilience, and affordable operation of the power system. Through the prize mechanism, OE identified two widespread data-related challenges for utilities—load modeling and data analysis automation—and offered an opportunity for utilities and teams of software engineers to identify additional challenges faced by utilities. After completing one round of the American-Made Digitizing Utilities Prize, OE, the National Renewable Energy Laboratory (NREL) as the prize administrator, and Pacific Northwest National Laboratory (PNNL) as the domain experts have compiled the results and lessons learned to feed into the second round of the prize.

29 ENERGY PLANNING, POLICY, AND ECONOMY↗

Framework Programmable Platform for the Advanced Software Development Workstation (FPP/ASDW). Demonstration framework document. Volume 2: Framework process description

In the second volume of the Demonstration Framework Document, the graphical representation of the demonstration framework is given. This second document was created to facilitate the reading and comprehension of the demonstration framework. It is designed to be viewed in parallel with Section 4.2 of the first volume to help give a picture of the relationships between the UOB's (Unit of Behavior) of the model. The model is quite large and the design team felt that this form of presentation would make it easier for the reader to get a feel for the processes described in this document. The IDEF3 (Process Description Capture Method) diagrams of the processes of an Information System Development are presented. Volume 1 describes the processes and the agents involved with each process, while this volume graphically shows the precedence relationships among the processes.

Mayer, Richard J.↗

Reconfigurable, Intelligently-Adaptive, Communication System, an SDR Platform

The Space Telecommunications Radio System (STRS) provides a common, consistent framework to abstract the application software from the radio platform hardware. STRS aims to reduce the cost and risk of using complex, configurable and reprogrammable radio systems across NASA missions. The Glenn Research Center (GRC) team made a software-defined radio (SDR) platform STRS compliant by adding an STRS operating environment and a field programmable gate array (FPGA) wrapper, capable of implementing each of the platforms interfaces, as well as a test waveform to exercise those interfaces. This effort serves to provide a framework toward waveform development on an STRS compliant platform to support future space communication systems for advanced exploration missions. Validated STRS compliant applications provided tested code with extensive documentation to potentially reduce risk, cost and efforts in development of space-deployable SDRs. This paper discusses the advantages of STRS, the integration of STRS onto a Reconfigurable, Intelligently-Adaptive, Communication System (RIACS) SDR platform, the sample waveform, and wrapper development efforts. The paper emphasizes the infusion of the STRS Architecture onto the RIACS platform for potential use in next generation SDRs for advance exploration missions.

space communications↗

Resilient Autonomy in the Face of Adversity

The NASA Resilient Autonomy Project developed a software framework that implemented a Run Time Assurance (RTA) architecture that leveraged ASTM International’s F3269 Industry Standard for safely bounding complex behavior in aircraft. This framework was called the Expandable Variable Autonomy Architecture, or EVAA. EVAA was developed during the height of the Covid-19 lockdown that caused the Resilient Autonomy team to pivot from flight test to distributed simulator testing. EVAA was developed to be platform and mission agnostic where platform specifics were behind a hardware abstraction layer that EVAA called a Coupler. EVAA was able to host multiple safety monitors that could resolve individual safety hazards. EVAA was able to resolve priority conflicts when multiple safety hazards needed to be resolved simultaneously and was able to resolve highly complex situations in a safe manner that could exceed human capabilities.

Ethan Williams↗

Micrometeoroid and Orbital Debris (MMOD) Testing, Ballistic Limit Equation Definition and Risk Assessment of the Exploration Extravehicular Mobility Unit (xEMU)

A well-known hazard associated with exposure to the space environment is the risk of failure due to an impact from a micrometeoroid and orbital debris (MMOD) particle. As NASA prepares to return astronauts to the moon with the Artemis program, the next generation of spacesuit is in development to support future extravehicular activities (EVAs.) An MMOD impact to the spacesuit is of great concern as a large leak could prevent an astronaut from safely reaching an airlock in time resulting in a loss of life. The exploration extravehicular mobility unit (xEMU) must meet MMOD requirements for multiple environments including those in low earth orbit (LEO) as well as the meteoroid and secondary lunar regolith ejecta environments found on the lunar surface. The subject of this paper is an internal xEMU configuration design developed by NASA Johnson Space Center (JSC) personnel. This paper will expand on the hypervelocity impact (HVI) testing and ballistic limit equation (BLE) definition work that was partially presented at the 2nd International Orbital De-bris (IOC-II) Conference held in Sugar Land, TX in December 2023. The xEMU shares similarities with the legacy Extravehicular Mobility Unit (EMU) spacesuit that is currently used for ISS EVAs, however differences in the layup (e.g., materials, thicknesses, and layers) of the fabric environmental protection garment (EPG), portable life support system (xPLSS) and helmet required an extensive test program to determine ballistic performance. Over 100 hypervelocity impact (HVI) tests were performed by the NASA/JSC HVIT and White Sands Test Facility (WSTF) teams on the xEMU EPG, xPLSS and helmet to generate ballistic limit equations (BLEs) for MMOD impacts. Additionally, over 50 low speed tests (< 1km/s) were performed by the NASA/JSC HVIT and Southwest Research Institute (SwRI) teams on the xEMU EPG, xPLSS and helmet to generate BLEs for lunar ejecta impacts. Post testing, ballistic limit equations used to define the performance of the various regions on the xEMU spacesuit were developed from a generic set of BLEs. The HVI and low speed testing was performed to establish a physical basis for the equations with the co-efficients and exponents of the generic BLEs adjusted to fit the test data. The xEMU BLEs were added to the NASA/JSC software application used for space-craft MMOD risk assessments (BUMPER-3). A finite element model (FEM) of the xEMU spacesuit, which defines the size and shape of the spacesuit as well as the locations of the various shielding configurations, was created based on a solid model provided by the xEMU program office. Using the FEM file and added xEMU BLEs, BUMPER-3 assessments of the xEMU spacesuit for probability of no penetration (PNP) were performed. For the LEO assessment of a typical ISS EVA, the orbital debris and meteoroids environments were defined using the latest engineering models, ORDEM 3.2 and MEM-3 respectively. The lunar sur-face assessment again used the MEM-3 engineering model to define the meteoroid environ-ment along with the current released lunar surface ejecta model, NASA SP-8013 (developed during the Apollo Program). The Space Team in the Natural Environments Branch at Mar-shall Space Flight Center (MSFC) will soon release the new Lunar Meteoroid Ejecta Engineering Model (LMEEM), at which time the xEMU lunar surface EVA will be reassessed. Assessment of the MMOD risk for an 8-hour, 2-person EVA in both LEO and on the lunar surface showed that the xEMU spacesuit meets the program technical requirement of 1 in 2500 failure odds. Similar to the legacy EMU spacesuit, the majority of the MMOD risk (96% of the LEO EVA risk and 99% of the lunar surface EVA risk) is concentrated in regions of xEMU that are comprised primarily of softgoods (arms, legs, and gloves) rather than the hardgoods (xPLSS, hard upper torso and helmet).

Micrometeoroid↗

Deploying and Tracking Software with NCCS Software Provisioning

The National Center for Computational Sciences (NCCS) at Oak Ridge National Laboratory has a long history of deploying ground-breaking leadership-class supercomputers for the U.S. Department of Energy. The latest in this line of supercomputers is Frontier, the first supercomputer to break the exascale barrier (1018 floating-point operations per second) on the TOP500 list. Frontier serves a wide array of scientific domains, from traditional simulation-based workloads to newer AI and Machine Learning workloads. To best serve the NCCS user community, NCCS uses Spack to deploy a comprehensive software stack of scientific software packages, providing straightforward access to these packages through Lmod Environment Modules. Maintaining a large software stack while also including multiple new compiler releases each year is a very time-consuming task. Additionally, it is not straightforward to provide a software stack alongside existing vendor-provided software such as the HPE/Cray Programming Environment (CPE), and existing CPE, Spack, and Lmod integration does not allow for multiple versions of GPU libraries such as AMD’s ROCm to be used. To address these challenges and shortcomings, NCCS has developed the NCCS Software Provisioning tool (NSP)1, a tool for deploying and monitoring software stacks on HPC systems. NSP allows NCCS to quickly and effectively provision software stacks from the ground up using template-driven recipes and configuration files. NSP is successfully deployed on Frontier and several other NCCS clusters, enabling the NCCS software team to quickly deploy software stacks for newly-released compilers, expand current software offerings, better support GPU-based software, and monitor Lmod module usage to identify unused software packages that can be removed from the software stack. In this work, we discuss the shortcomings of the previous CPE, Spack, and Lmod usage at NCCS, provide further details on the implementation and structure of NSP, then discuss the benefits that NSP provides.

Rentschler, Asa [ORNL] (ORCID:0009000597694743)↗

Empirical studies of design software: Implications for software engineering environments

The empirical studies team of MCC's Design Process Group conducted three studies in 1986-87 in order to gather data on professionals designing software systems in a range of situations. The first study (the Lift Experiment) used thinking aloud protocols in a controlled laboratory setting to study the cognitive processes of individual designers. The second study (the Object Server Project) involved the observation, videotaping, and data collection of a design team of a medium-sized development project over several months in order to study team dynamics. The third study (the Field Study) involved interviews with the personnel from 19 large development projects in the MCC shareholders in order to study how the process of design is affected by organizationl and project behavior. The focus of this report will be on key observations of design process (at several levels) and their implications for the design of environments.

Krasner, Herb↗

Countermeasures for Mitigation of Sensorimotor Decrements Following Head-Down Bed Rest

BACKGROUND Astronauts experience postflight disturbances in postural and locomotor control due to sensorimotor adaptations during spaceflight. These alterations may have adverse consequences if a rapid egress is required after landing. Although exercise is partially effective for mitigating cardiovascular and muscular deconditioning, additional countermeasures are needed to further preserve sensorimotor function for exploration missions. We have identified proprioceptive training and electrical muscle stimulation (EMS) as promising in-flight countermeasures. Since prolonged head down bed rest (HDBR) is a spaceflight analog for body unloading and causes postural and locomotor control decrements that parallel those observed after spaceflight, it can be used to accelerate the development of these countermeasures. METHODS This study will determine the effects of proprioceptive training and EMS on functional task performance and sensorimotor function following 60 days of 6° HDBR. Subjects will be randomly assigned to one of four groups: 1) an EMS arm, 2) a proprioceptive training arm, 3) an exercise plus proprioceptive training arm, and 4) a control arm. The EMS countermeasure will include daily bilateral stimulation of the quadriceps femoris muscle (30 minutes per session). Proprioceptive training will be performed three days per week (20 minutes per session) consisting of body-loaded postural tasks in the horizontal position on an air bearing sled. Exercise training will mimic current protocols used on the International Space Station, but treadmill aerobic exercise will be replaced with additional cycling aerobic exercise. Primary outcome measures will include pre and post HDBR functional tests that are representative of high priority exploration mission tasks and require high demand for dynamic control of postural stability. Additional measures will be used to identify the key physiological factors contributing to countermeasure benefits. Given the constrained samples size, a Bayesian modelling approach will be used to quantify the probability that there is an effect of a given magnitude. COUNTERMEASURE UPDATES Proprioceptive countermeasure design enhancements and human in the loop pilot testing continued through the Crew Health Countermeasures (CHC) Systems Capability Leadership Team (SCLT). The primary goals of this work were to enhance the visual feedback system’s capabilities and develop a proprioceptive training program for 60 days of HDBR. Six healthy non-astronaut volunteers participated in four pilot training sessions to systematically examine how each training variable (e.g., axial load, foot placement, and software profile) affects the overall proprioceptive challenge. The resulting training program will maintain an appropriate challenge during 60 days of HDBR by progressively decreasing the subject’s base of support, increasing tilt board target distances, and increasing axial loads using both subjective verbal feedback and objective performance data. RELEVANCE The deliverable from this project will be proof-of-concept sensorimotor countermeasure designs for functional task performance with full assessment of efficacy in a spaceflight analog. If the countermeasures are effective, they will be translated for validation with the suite of operationally implemented in-flight countermeasures.

T R Macaulay↗

Automated System Checkout to Support Predictive Maintenance for the Reusable Launch Vehicle

The Propulsion Checkout and Control System (PCCS) is a predictive maintenance software system. The real-time checkout procedures and diagnostics are designed to detect components that need maintenance based on their condition, rather than using more conventional approaches such as scheduled or reliability centered maintenance. Predictive maintenance can reduce turn-around time and cost and increase safety as compared to conventional maintenance approaches. Real-time sensor validation, limit checking, statistical anomaly detection, and failure prediction based on simulation models are employed. Multi-signal models, useful for testability analysis during system design, are used during the operational phase to detect and isolate degraded or failed components. The TEAMS-RT real-time diagnostic engine was developed to utilize the multi-signal models by Qualtech Systems, Inc. Capability of predicting the maintenance condition was successfully demonstrated with a variety of data, from simulation to actual operation on the Integrated Propulsion Technology Demonstrator (IPTD) at Marshall Space Flight Center (MSFC). Playback of IPTD valve actuations for feature recognition updates identified an otherwise undetectable Main Propulsion System 12 inch prevalve degradation. The algorithms were loaded into the Propulsion Checkout and Control System for further development and are the first known application of predictive Integrated Vehicle Health Management to an operational cryogenic testbed. The software performed successfully in real-time, meeting the required performance goal of 1 second cycle time.

Patterson-Hine, Ann↗

An Optimization Approach to Support Science Decision Making for Lunar Surface Exploration

Introduction: Scientific exploration is one of the three pillars of NASA’s Moon2Mars architecture, with crew surface extra vehicular activities (EVA) serving a critical enabling function. Development of surface EVA operational planning and execution, specifically integrating science and flight control teams (FCT), is currently being explored through analog scenarios. This integration, exercised, for example, through the Joint EVA and Hu-man Surface Mobility Test Team (JETT), allows for science input on EVA activities in near real-time through a Science Evaluation Room (SER), or Arte-mis science backroom, which integrates with the broader FCT through the Science Officer. The SER works within the FCT to support dynamic EVA planning in response to changes in operational constraints as well as science opportunities and re-prioritization, increasing the mission science return and accelerating the accomplishment of the Moon2Mars science objectives. The SER works within the FCT to provide recommendations to traverse execution in near real-time. One challenge is the requirement to deliver SER inputs to the FCT on operationally relevant timelines. Failure to do so may result in suboptimal execution of science exploration EVAs or even loss of key science objectives. To close this gap, we present a network optimization tool to allow the SER to provide rapid input to the FCT in response to changes in operational constraints or science opportunities. Inputs are predicated on approved science objectives, and clear rationale must be provided to the FCT for any requested change. Accordingly, this tool incorporates the Science Traceability Matrix (STM), SER prioritization scheme, and station characterization and action planning with operational constraints such as duration, traverse speed, and distance to maximize science objectives based on SER priorities, consistent with FCT operational requirements. Method: As a proof of concept, we used an existing linear programing software package used to simulate optimal routes through cellular metabolism. We built a Demonstrative Model with three STM objectives and four stations on a region of the Moon. The objectives were given an arbitrary prioritization and mapped to the stations through four possible crew actions. (Figs. 1 and 2). This station to STM mapping is consistent with the method used by the JETT5 Science Team to develop analog surface EVA science planning. We used a grid system with the landing site at the origin and the four stations placed across the positive x,y quadrant. Actions were assigned to each station and the accomplishment of those actions resulted in a numerical “reward” based on the ability of that action to achieve science objectives. The aggregate reward from each individual STM objective contributes to a global score (Science Yield), weighted by its priority. Operational constraints included a requirement to start and end at the landing site, 5 minutes each for initial station characterization and “clean up,” and variable total EVA time, traverse rate (fixed to 0.5 meters per second in our example), and time to perform each action (10, 5, 7, and 15 min for actions 1, 2, 3, and 4, respectively). Additional constraints and variables will be added in the future (e.g., sample mass, number of stations, traverse route constraints, illumination). Optimization. We converted the connections (arcs) between these stations (nodes) into a mixed integer linear programming optimization problem (arcs = constraints, nodes = variables) with the objective to maximize Science Yield. For any action, the Science Yield is equal to the relevance of that action to an STM objective [3, 2, and 1 point(s) for High, Med., and Low relevance, respectively], multiplied by the STM Objective Priority [3, 2, and 1 point(s) for High, Med., and Low priority, respectively]. This resulted in a model that computes the optimal station and action combination to maximize the Science Yield. These weightings can be adjusted by the SER as desired. Results: We explored three test cases for the Demonstrative Model. First, we set the maximum EVA duration to 120 minutes and computed the optimal route (Fig. 3A). The model suggested per-forming Actions 1 and 2 at Station P01, followed by Actions 1 and 2 at Station P02, and finally Actions 1 and 3 at Station P04 before returning to the Landing Site. Second, we adjusted the STM Objective Priori-ty order and computed the new optimal route (Fig. 3B). Under this situation, the model suggested per-forming all Actions at Station P02 followed by all Actions at Station P03. The previous test cases were relevant to SER planning activities. Next, we explored providing mid-EVA replanning input to the FCT. Scenario: While executing the Route in Fig. 3A the crew finishes at Station P01 and FCT decides that the EVA needs to finish in 45 minutes back at the Landing Site. FCT asks SER to recommend changes to the plan to accommodate this operation-al change. Using the model and incorporating these new constraints (start at Station P01, max. time of 45 min), the model suggested performing Actions 2 and 4 at Station P03 (Fig. 4), requiring 41 minutes to complete and return to the Landing Site. Interestingly, Station 3 was not part of the original route. Using the model, we determined the EVA would need 66 minutes, instead of 45, in order for the original Station P04 to yield a larger Science Yield than Station P03. The parametrization and simulation was per-formed in less than a minute, demonstrating the operational relevance of the approach. Future Efforts: The results from the Demonstrative Model suggest this tool can accelerate SER decision making on operationally relevant timelines. Use in analog activities, such as JETT5 or follow-ons, which have over a dozen stations for a crew to explore and over a dozen actions per station, will provide needed validation of the utility of this tool for planning EVAs, replanning mid-EVA, or planning follow-on EVAs based on previous results. Further integration with FCT execution monitoring tools may provide additional efficiency gains, al-lowing rapid and iterative exploration of operation-al and science decision space by the FCT and SER.

Science Operations↗

Crew Performance Support System to Aid in Anomaly Resolution: Concept of Operations

As missions progress into deep space, communication delays and disruptions will disenable the crew’s reliance on Earth experts. There are also limitations in the amount of data that can be downlinked to the ground. It is prudent to assume that critical, complex vehicle or habitat sub-systems will malfunction at a time when a lunar or Mars’ crew cannot rely on the Earth-Support team to detect, diagnose and resolve the problem and it is impractical to expect a small crew to step-in with the same level of expertise as 50+ authorities. The crew will need novel processes and advanced technological support to independently identify and resolve safety- and time-critical anomalies. That a self-reliant crew is unable to respond appropriately to time-critical anomalies is a significant risk to crew safety and mission success. This risk is driven by several factors; novel and unanticipated anomalies would not have been trained pre-flight, the crew could forget their pre-flight training or spaceflight stressors could impair the crew’s problem-solving ability. At last year’s IWS, Beard reported that a single spaceflight stressor (elevated CO2) could undermine the crew’s ability to independently respond to emergencies. Concept of Operations (ConOps) provide a common view of future system functions to all stakeholders. For the current project, a ConOps was developed that describes the operational processes, practices and capabilities needed by a crew of astronauts on deep space missions to autonomously respond to anticipated and unanticipated anomalies. It is crucial to recognize that, as of August 2018 existing technologies are unable to effectively support crew anomaly response to unanticipated events. “Intelligent technology” has not reached a maturity level that permits generalizing a solution to novel situations. For example, to train intelligent technology requires volumes of data that do not exist. The complexities involved in a manned mission to Mars cannot be compared to sending rovers to Mars using scripted software. This ConOps proposes a Crew Performance Support System (CPSS) that will push NASA and its industry partners toward what will be required for a safe and successful manned mission to Mars. Anomaly resolution during a deep space mission will take place within a dynamic, or changing, context. The figure to the left shows five broad contextual variables: the organizational culture, mission context, system characteristics, team characteristics and individual characteristics. The yellow arrow indicates that spaceflight and task-related stressors can affect system, team and individual crewmember characteristics and therefore anomaly response potential. The figure depicts a protective umbrella of Human-System Integration (HSI) principles that should be instituted during CPSS development including a balanced workload, shared situation awareness and building an appropriate level of trust in the automation. The figure also depicts two interrelated and cooperative components, an HSI Data System and other Enabling Capabilities will be required to support crew anomaly response and Earth-Support situation awareness. As we journey from ISS to Gateway to Mars, multiple, simultaneous and integrated research and development efforts (i.e., support systems co-evolution) must be implemented to meet the problem-solving challenges a self-reliant crew will face on a Mars’ mission. The crossovers between the capabilities are just as important as the discrete capabilities themselves. As the capabilities mature, the lines between the support subdomains will blur and an integrated system will emerge. The ConOps summarizes current knowledge about how highly trained people solve anomalies in safety- and time-critical situations, describes a group of capabilities that could help to reduce the extant risk and documents requirements levied on additional systems that provides critical inputs to the CPSS. Scenarios are used to promote a shared understanding of processes, practices and technological goals needed for safe and productive manned missions beyond LEO.

HSIA risk↗

A Cast of Thousands: How the IDEAS Productivity Project Has Advanced Software Productivity and Sustainability

Computational and data-enabled science and engineering are revolutionizing advances throughout science and society, at all scales of computing. For example, teams in the U.S. Department of Energy’s Exascale Computing Project have been tackling new frontiers in modeling, simulation, and analysis by exploiting unprecedented exascale computing capabilities—building an advanced software ecosystem that supports next-generation applications and addresses disruptive changes in computer architectures. However, concerns are growing about the productivity of the developers of scientific software. Members of the Interoperable Design of Extreme-scale Application Software project serve as catalysts to address these challenges through fostering software communities, incubating and curating methodologies and resources, and disseminating knowledge to advance developer productivity and software sustainability. This article discusses how these synergistic activities are advancing scientific discovery—mitigating technical risks by building a firmer foundation for reproducible, sustainable science at all scales of computing, from laptops to clusters to exascale and beyond.

97 MATHEMATICS AND COMPUTING↗