SEARCH · Search NASA

Results for “Crew Autonomous Scheduling Test”

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.

31 records · Page 2

All sources NASA NTRS DOE OSTI

NASA NTRSDate not supplied

Demonstration of Two Extended Visual Line of Sight Methods for Urban UAV Operations

This report describes two extended visual line of sight (EVLOS) methods developed and utilized during two flight campaigns over the campus of NASA Langley Research Center (LaRC): a chase vehicle method and a radio controlled (RC) pilot handoff method. These campaigns were performed to (a) evaluate small unmanned aerial system (sUAS) flight beyond the visual line of sight (BVLOS) of the ground control station operator and (b) test technologies under development to enable a transition from EVLOS to BVLOS operations. While an autonomous waypoint-based operational approach enabled minimal pilot intervention in both methods, range containment was enforced (a) manually via continual pilot visual monitoring and (b) autonomously via on-board contingency landing autonomy triggerable at the boundary of stay-in geofences. In the thirty-nine flights which utilized the chase vehicle, the pilot followed the sUAS flying a 1.2 km path at 40m altitude over urban streets. In the fifteen flights which utilized pilot handoff, a pilot at one end of a 1.5 km path initiated the flight at 120m altitude over buildings and trees, and at the midway point of the path transferred radio control to a pilot at the other end. In comparison, the chase vehicle method requires less ground crew and simpler avionics, while the pilot handoff method avoids schedule risk arising from street traffic congestion but better replicates actual direct routing for BVLOS flights. Collision risk with another aircraft was introduced in both campaigns and mitigated with the same manual and autonomous methods. Results from these campaigns serve as a basis for planned BVLOS operations at NASA LaRC.

Nicholas Rymer↗

NASA NTRS2014

NASA's Space Launch System: Momentum Builds Towards First Launch

NASA's Space Launch System (SLS) is gaining momentum programmatically and technically toward the first launch of a new exploration-class heavy lift launch vehicle for international exploration and science initiatives. The SLS comprises an architecture that begins with a vehicle capable of launching 70 metric tons (t) into low Earth orbit. Its first mission will be the launch of the Orion Multi-Purpose Crew Vehicle (MPCV) on its first autonomous flight beyond the Moon and back. SLS will also launch the first Orion crewed flight in 2021. SLS can evolve to a 130-t lift capability and serve as a baseline for numerous robotic and human missions ranging from a Mars sample return to delivering the first astronauts to explore another planet. Managed by NASA's Marshall Space Flight Center, the SLS Program formally transitioned from the formulation phase to implementation with the successful completion of the rigorous Key Decision Point C review in 2014. At KDP-C, the Agency Planning Management Council determines the readiness of a program to go to the next life-cycle phase and makes technical, cost, and schedule commitments to its external stakeholders. As a result, the Agency authorized the Program to move forward to Critical Design Review, scheduled for 2015, and a launch readiness date of November 2018. Every SLS element is currently in testing or test preparations. The Program shipped its first flight hardware in 2014 in preparation for Orion's Exploration Flight Test-1 (EFT-1) launch on a Delta IV Heavy rocket in December, a significant first step toward human journeys into deep space. Accomplishments during 2014 included manufacture of Core Stage test articles and preparations for qualification testing the Solid Rocket Boosters and the RS-25 Core Stage engines. SLS was conceived with the goals of safety, affordability, and sustainability, while also providing unprecedented capability for human exploration and scientific discovery beyond Earth orbit. In an environment of economic challenges, the nationwide SLS team continues to meet ambitious budget and schedule targets through the studied use of hardware, infrastructure, and workforce investments the United States has already made in the last half century, while selectively using new technologies for design, manufacturing, and testing, as well as streamlined management approaches that have increased decision velocity and reduced associated costs. This paper will summarize recent SLS Program technical accomplishments, as well as the challenges and opportunities ahead for the most powerful and capable launch vehicle in history.

May, Todd↗

NASA NTRS2024

Crew Health and Performance Integrated Data Architecture (CHP-IDA) TechPort May 2024

Future exploration missions to Mars will have increased need for crew autonomy. Crew Health & Performance (CHP) related data on the ISS is currently, manually downlinked and in disparate locations, which limits crew autonomy for future missions. The CHP-IDA project is developing a backend data system platform that grants the ability to seamlessly collect, store, process, and display CHP-related data for exploration missions. This platform allows for integration of data and advanced analytics that offer crew and ground teams better insight into the crew’s health and performance. It also enables applications that can improve the crew’s ability to provide more autonomous medical care during exploration missions. Data will be collected automatically to reduce crew and ground team time and effort and will synchronize across all in-mission vehicles, habitats, and ground as communication delay permits. The Human Research Program’s (HRP) Medical Data Architecture (MDA) project focused on this backend data architecture but for medical data only. The CHP-IDA project, a joint effort between HRP’s Exploration Medical Capability (ExMC) element and the Exploration Medical Integrated Product Team (XMIPT), expands this capability to all relevant CHP-related data. The additional inputs from nutrition, environment, exercise, radiation, and any other relevant sources will give more insight into crew’s health and performance. Currently, the Human Systems Engineering and Integration Division at Johnson Space Center (JSC) is designing the system. The team completed a system requirements review (SRR) in FY22 and now the focus is on core software development, testbed buildup, and use case scenario demonstration. An end-to-end demonstration with multiple data sources across CHP domains is schedule for the end of FY24 where all three focus areas will be displayed. Following this ground demo, the software will be completed, tested, and validated for flight.

Courtney M Schkurko↗

NASA NTRS2014

NASA's Space Launch System Development Status

Development of the National Aeronautics and Space Administration's (NASA's) Space Launch System (SLS) heavy lift rocket is shifting from the formulation phase into the implementation phase in 2014, a little more than 3 years after formal program establishment. Current development is focused on delivering a vehicle capable of launching 70 metric tons (t) into low Earth orbit. This "Block 1" configuration will launch the Orion Multi-Purpose Crew Vehicle (MPCV) on its first autonomous flight beyond the Moon and back in December 2017, followed by its first crewed flight in 2021. SLS can evolve to a130t lift capability and serve as a baseline for numerous robotic and human missions ranging from a Mars sample return to delivering the first astronauts to explore another planet. Benefits associated with its unprecedented mass and volume include reduced trip times and simplified payload design. Every SLS element achieved significant, tangible progress over the past year. Among the Program's many accomplishments are: manufacture of core stage test barrels and domes; testing of Solid Rocket Booster development hardware including thrust vector controls and avionics; planning for RS- 25 core stage engine testing; and more than 4,000 wind tunnel runs to refine vehicle configuration, trajectory, and guidance. The Program shipped its first flight hardware - the Multi-Purpose Crew Vehicle Stage Adapter (MSA) - to the United Launch Alliance for integration with the Delta IV heavy rocket that will launch an Orion test article in 2014 from NASA's Kennedy Space Center. The Program successfully completed Preliminary Design Review in 2013 and will complete Key Decision Point C in 2014. NASA has authorized the Program to move forward to Critical Design Review, scheduled for 2015 and a December 2017 first launch. The Program's success to date is due to prudent use of proven technology, infrastructure, and workforce from the Saturn and Space Shuttle programs, a streamlined management approach, and judicious use of new technologies. The result is a safe, affordable, sustainable, and evolutionary path to development of an unprecedented capability for future missions across the solar system. In an environment of economic challenges, the nationwide SLS team continues to meet ambitious budget and schedule targets. This paper will discuss SLS Program and technical accomplishments over the past year and provide a look at the milestones and challenges ahead.

Lyles, Garry↗

NASA NTRSDate not supplied

Clinical Decision Support Project

As NASA plans for exploration missions into deep space, significant challenges are realized due to the distance from Earth. Beside the effects of microgravity and radiation exposure, the astronauts face the additional constraints of isolation, lack of resupply, increasingly difficult evacuation, and delayed and disrupted communication with ground-based medical care providers. These constraints require a paradigm shift from current medical care where crews rely on the real-time communications with ground-based medical care providers toward Earth-independent medical operations for astronaut medical care. Medical expertise and decision-making are ground-based for current International Space Station and planned Lunar missions. However, a deep space exploration crew will need to autonomously perform the detection, diagnosis, treatment, and prevention of medical conditions. One approach to provide Earth-independent medical operations is to augment the requisite knowledge, skills, and abilities (KSAs) of a time-constrained crew—operating under stressful conditions, combatting fatigue, and facing a potential medical crisis—with a robust clinical decision support system (CDSS). The CDSS is envisioned as an integrated, software-based tool deployed on a laptop computer or handheld device. The CDSS will assist the crew and ground support when interacting with knowledge/data bases (e.g. records, pharmacy, schedule), instrumentation (e.g. imaging, physiological monitoring devices), and habitat (e.g. wellness system, task performance system) and vehicle systems (e.g. environmental system, communication system). In addition, the human interface will employ a context-based approach that accounts for the crew’s situation. Thus, extraneous and clinically/operationally non-relevant information are reduced to avoid an increase in cognitive load. The framework of an ideal spaceflight CDSS is to include core and advanced analytical features that maintain a flexible platform for integrating new technology in the future. The Exploration Medical Capability (ExMC) Element of the Human Research Program (HRP) is expanding the boundaries of space medical systems to advance the care of astronauts on future exploration missions beyond low Earth orbit by actively identifying and testing next-generation medical care and crew health maintenance technologies. The Clinical Decision Support (CDS) project addressed ap Medical-701 within the Inflight Medical Conditions risk: “We need to increase inflight medical capabilities and identify new capabilities that (a) maximize benefit and/or (b) reduce “costs” on human system/mission/vehicle resources.” Though mass, volume, and power will face increasing constraints, the projected computational capabilities of spacecraft systems will increase exponentially as information technology advances in this decade and beyond. Hence, data, software, and computational resources will play an essential and synergistic role in maintaining crew health, wellness, and performance in deep space missions. The focus of the CDS project was to develop recommended requirements for an in-vehicle CDSS that acts as a ‘virtual assistant’ for delivering optimal health, performance, and medical care during exploration missions. In fiscal year 2022 (FY22), the CDS project was chartered to baseline and/or revise all CDS project related documentation and update the CDS project model to include the revised CDSS Concept of Operations, revised systems-based modeling language (SysML) activity diagrams, and baseline requirements. The focus of this presentation will be an overview of the CDS products and CDS model content.

Decision Support↗

NASA NTRS2014

Space Launch System Development Status

Development of NASA's Space Launch System (SLS) heavy lift rocket is shifting from the formulation phase into the implementation phase in 2014, a little more than three years after formal program approval. Current development is focused on delivering a vehicle capable of launching 70 metric tons (t) into low Earth orbit. This "Block 1" configuration will launch the Orion Multi-Purpose Crew Vehicle (MPCV) on its first autonomous flight beyond the Moon and back in December 2017, followed by its first crewed flight in 2021. SLS can evolve to a130-t lift capability and serve as a baseline for numerous robotic and human missions ranging from a Mars sample return to delivering the first astronauts to explore another planet. Benefits associated with its unprecedented mass and volume include reduced trip times and simplified payload design. Every SLS element achieved significant, tangible progress over the past year. Among the Program's many accomplishments are: manufacture of Core Stage test panels; testing of Solid Rocket Booster development hardware including thrust vector controls and avionics; planning for testing the RS-25 Core Stage engine; and more than 4,000 wind tunnel runs to refine vehicle configuration, trajectory, and guidance. The Program shipped its first flight hardware - the Multi-Purpose Crew Vehicle Stage Adapter (MSA) - to the United Launch Alliance for integration with the Delta IV heavy rocket that will launch an Orion test article in 2014 from NASA's Kennedy Space Center. Objectives of this Earth-orbit flight include validating the performance of Orion's heat shield and the MSA design, which will be manufactured again for SLS missions to deep space. The Program successfully completed Preliminary Design Review in 2013 and Key Decision Point C in early 2014. NASA has authorized the Program to move forward to Critical Design Review, scheduled for 2015 and a December 2017 first launch. The Program's success to date is due to prudent use of proven technology, infrastructure, and workforce from the Saturn and Space Shuttle programs, a streamlined management approach, and judicious use of new technologies. The result is a safe, affordable, sustainable, and evolutionary path to development of an unprecedented capability for future missions across the solar system. In an environment of economic challenges, the nationwide SLS team continues to meet ambitious budget and schedule targets. This paper will discuss SLS program and technical accomplishments over the past year and provide a look at the milestones and challenges ahead.

Lyles, Garry↗

NASA NTRS1994

Robotic technologies of the Flight Telerobotic Servicer (FTS) including fault tolerance

The original FTS concept for Space Station Freedom (SSF) was to provide telerobotic assistance to enhance crew activity and safety and to reduce crew EVA (Extra Vehicular Activity) activity. The first flight of the FTS manipulator systems would demonstrate several candidate tasks and would verify manipulator performance parameters. These first flight tasks included unlocking a SSF Truss Joint, mating/demating a fluid coupling, contact following of a contour board, demonstrating peg-in-hole assembly, and grasping and moving a mass. Future tasks foreseen for the FTS system included ORU (Orbit Replaceable Unit) change-out, Hubble Space Telescope Servicing, Gamma Ray Observatory refueling, and several in-situ SSF servicing and maintenance tasks. Operation of the FTS was planned to evolve from teleoperation to fully autonomous execution of many tasks. This wide range of mission tasks combined with the desire to evolve toward fully autonomy forced several requirements which may seen extremely demanding to the telerobotics community. The FTS requirements appear to have been created to accommodate the open-ended evolution plan such that operational evolution would not be impeded by function limitations. A recommendation arising from the FTS program to remedy the possible impacts from such ambitious requirements is to analyze candidate robotic tasks. Based on these task analyses, operational impacts against development impacts were weighed prior to requirements definition. Many of the FTS requirements discussed in the following sections greatly influenced the development cost and schedule of the FTS manipulator. The FTS manipulator has been assembled at Martin Marietta and is currently in testing. Successful component tests indicate a manipulator which achieves unprecedented performance specifications.

Chladek, John T.↗

NASA NTRSDate not supplied

CLINICAL DECISION SUPPORT: PATH TO FUNCTIONAL REQUIREMENTS

Long-duration, deep-space exploration missions present significant challenges to crew health and performance. These challenges include the individual and combined effects of microgravity, radiation exposure, isolation, limited resources (mass, volume, power, data and crew time), limited options for evacuation and those associated with delayed or constrained communications, all of which demand greater crew autonomy. Specifically, as the communication delays intensify the further we explore space, the unqualified need for Earth-independent medical operations focused on autonomous diagnosis, treatment and prevention will be key to mission continuation and success. To augment the requisite knowledge, skills and abilities (KSAs) of a time-constrained crew operating under stressful conditions, combatting fatigue, and facing a potential medical crisis, a robust clinical decision support system (CDSS) is a probable solution that would facilitate, guide and inform Earth-independent medical operations, while assisting crewmembers through various clinical presentations. The Exploration Medical Capability (ExMC) Element of the Human Research Program (HRP) is expanding the boundaries of space medical systems to advance the care of astronauts on future exploration missions beyond low Earth orbit. ExMC is actively identifying and testing next-generation medical care and crew health maintenance technologies. The Clinical Decision Support (CDS) project addresses gap Medical-701 within the Inflight Medical Conditions risk: “Enhance medical capabilities within an exploration medical system.” Though mass, volume, and power will face increasing constraints, the projected computational capabilities of spacecraft systems will increase exponentially as information technology continues to advance this decade and beyond. Hence, data, software and computational resources will play an essential and synergistic role in maintaining crew health, wellness and performance in deep space missions. The focus of the CDS project is to develop recommended requirements for an in-vehicle CDSS that acts as a ‘virtual assistant’ for delivering optimal health, performance and medical care during exploration missions. The CDSS is envisioned as an integrated, software-based tool deployed on a laptop computer or handheld device. The CDSS will assist the crew and ground support when interacting with knowledge/databases (e.g. records, pharmacy, schedule), instrumentation (e.g. imaging, physiological monitoring devices), and habitat (e.g. wellness system, task performance system) and vehicle systems (e.g. environmental system, communication system). In addition, the human interface will employ a context-based approach that accounts for the crew’s situation. Thus, extraneous and clinically/operationally non-relevant information are reduced to avoid an increase in cognitive load. The framework of an ideal spaceflight CDSS is to include core and advanced analytical features that incorporate work from collaborators yet maintain a flexible platform for integrating new technology in the future. In fiscal year 2021 (FY21), the CDS project identified requirements through two primary mechanisms: (i) the development of software implementation prototypes and (ii) the application of systems engineering processes. The CDS project developed and tested a series of increasingly complex system prototypes that were based on use cases derived from the CDSS concept of operations (ConOps). These software implementations yielded insights on CDSS functionality as well as lessons learned that provided the initial requirements for CDSS capability. By applying a systems engineering (SE) approach, medical scenarios provided in the ConOps and the use cases for software implementation underwent functional decomposition to identify CDSS functionality. Also, systems-based modeling language (SysML) tools such as activity diagrams were developed from the same ConOps and use cases to identify CDSS functionality. The lessons learned from software implementation defined both specific requirements and broad areas of requirements. Within these defined broad requirement areas, further analysis of the SE products identified specific capability that resulted in the final functional requirements. In summary, the software prototypes, functional decomposition of the ConOps and use cases, and SysML diagrams provided the basis for the CDSS requirements developed in FY21. In the upcoming year, these requirements will be refined for their final ExMC baseline review in latter FY22.

clinical decision support↗

NASA NTRSDate not supplied

Clinical Decision Support: Path to Functional Requirements

Clinical decision support↗

NASA NTRS2015

A Vehicle Management End-to-End Testing and Analysis Platform for Validation of Mission and Fault Management Algorithms to Reduce Risk for NASA's Space Launch System

The development of the Space Launch System (SLS) launch vehicle requires cross discipline teams with extensive knowledge of launch vehicle subsystems, information theory, and autonomous algorithms dealing with all operations from pre-launch through on orbit operations. The characteristics of these systems must be matched with the autonomous algorithm monitoring and mitigation capabilities for accurate control and response to abnormal conditions throughout all vehicle mission flight phases, including precipitating safing actions and crew aborts. This presents a large complex systems engineering challenge being addressed in part by focusing on the specific subsystems handling of off-nominal mission and fault tolerance. Using traditional model based system and software engineering design principles from the Unified Modeling Language (UML), the Mission and Fault Management (M&FM) algorithms are crafted and vetted in specialized Integrated Development Teams composed of multiple development disciplines. NASA also has formed an M&FM team for addressing fault management early in the development lifecycle. This team has developed a dedicated Vehicle Management End-to-End Testbed (VMET) that integrates specific M&FM algorithms, specialized nominal and off-nominal test cases, and vendor-supplied physics-based launch vehicle subsystem models. The flexibility of VMET enables thorough testing of the M&FM algorithms by providing configurable suites of both nominal and off-nominal test cases to validate the algorithms utilizing actual subsystem models. The intent is to validate the algorithms and substantiate them with performance baselines for each of the vehicle subsystems in an independent platform exterior to flight software test processes. In any software development process there is inherent risk in the interpretation and implementation of concepts into software through requirements and test processes. Risk reduction is addressed by working with other organizations such as S&MA, Structures and Environments, GNC, Orion, the Crew Office, Flight Operations, and Ground Operations by assessing performance of the M&FM algorithms in terms of their ability to reduce Loss of Mission and Loss of Crew probabilities. In addition, through state machine and diagnostic modeling, analysis efforts investigate a broader suite of failure effects and detection and responses that can be tested in VMET and confirm that responses do not create additional risks or cause undesired states through interactive dynamic effects with other algorithms and systems. VMET further contributes to risk reduction by prototyping and exercising the M&FM algorithms early in their implementation and without any inherent hindrances such as meeting FSW processor scheduling constraints due to their target platform - ARINC 653 partitioned OS, resource limitations, and other factors related to integration with other subsystems not directly involved with M&FM. The plan for VMET encompasses testing the original M&FM algorithms coded in the same C++ language and state machine architectural concepts as that used by Flight Software. This enables the development of performance standards and test cases to characterize the M&FM algorithms and sets a benchmark from which to measure the effectiveness of M&FM algorithms performance in the FSW development and test processes. This paper is outlined in a systematic fashion analogous to a lifecycle process flow for engineering development of algorithms into software and testing. Section I describes the NASA SLS M&FM context, presenting the current infrastructure, leading principles, methods, and participants. Section II defines the testing philosophy of the M&FM algorithms as related to VMET followed by section III, which presents the modeling methods of the algorithms to be tested and validated in VMET. Its details are then further presented in section IV followed by Section V presenting integration, test status, and state analysis. Finally, section VI addresses the summary and forward directions followed by the appendices presenting relevant information on terminology and documentation.

Trevino, Luis↗

NASA NTRS2015

A Vehicle Management End-to-End Testing and Analysis Platform for Validation of Mission and Fault Management Algorithms to Reduce Risk for NASA's Space Launch System

The engineering development of the new Space Launch System (SLS) launch vehicle requires cross discipline teams with extensive knowledge of launch vehicle subsystems, information theory, and autonomous algorithms dealing with all operations from pre-launch through on orbit operations. The characteristics of these spacecraft systems must be matched with the autonomous algorithm monitoring and mitigation capabilities for accurate control and response to abnormal conditions throughout all vehicle mission flight phases, including precipitating safing actions and crew aborts. This presents a large and complex system engineering challenge, which is being addressed in part by focusing on the specific subsystems involved in the handling of off-nominal mission and fault tolerance with response management. Using traditional model based system and software engineering design principles from the Unified Modeling Language (UML) and Systems Modeling Language (SysML), the Mission and Fault Management (M&FM) algorithms for the vehicle are crafted and vetted in specialized Integrated Development Teams (IDTs) composed of multiple development disciplines such as Systems Engineering (SE), Flight Software (FSW), Safety and Mission Assurance (S&MA) and the major subsystems and vehicle elements such as Main Propulsion Systems (MPS), boosters, avionics, Guidance, Navigation, and Control (GNC), Thrust Vector Control (TVC), and liquid engines. These model based algorithms and their development lifecycle from inception through Flight Software certification are an important focus of this development effort to further insure reliable detection and response to off-nominal vehicle states during all phases of vehicle operation from pre-launch through end of flight. NASA formed a dedicated M&FM team for addressing fault management early in the development lifecycle for the SLS initiative. As part of the development of the M&FM capabilities, this team has developed a dedicated testbed that integrates specific M&FM algorithms, specialized nominal and off-nominal test cases, and vendor-supplied physics-based launch vehicle subsystem models. Additionally, the team has developed processes for implementing and validating these algorithms for concept validation and risk reduction for the SLS program. The flexibility of the Vehicle Management End-to-end Testbed (VMET) enables thorough testing of the M&FM algorithms by providing configurable suites of both nominal and off-nominal test cases to validate the developed algorithms utilizing actual subsystem models such as MPS. The intent of VMET is to validate the M&FM algorithms and substantiate them with performance baselines for each of the target vehicle subsystems in an independent platform exterior to the flight software development infrastructure and its related testing entities. In any software development process there is inherent risk in the interpretation and implementation of concepts into software through requirements and test cases into flight software compounded with potential human errors throughout the development lifecycle. Risk reduction is addressed by the M&FM analysis group working with other organizations such as S&MA, Structures and Environments, GNC, Orion, the Crew Office, Flight Operations, and Ground Operations by assessing performance of the M&FM algorithms in terms of their ability to reduce Loss of Mission and Loss of Crew probabilities. In addition, through state machine and diagnostic modeling, analysis efforts investigate a broader suite of failure effects and associated detection and responses that can be tested in VMET to ensure that failures can be detected, and confirm that responses do not create additional risks or cause undesired states through interactive dynamic effects with other algorithms and systems. VMET further contributes to risk reduction by prototyping and exercising the M&FM algorithms early in their implementation and without any inherent hindrances such as meeting FSW processor scheduling constraints due to their target platform - ARINC 653 partitioned OS, resource limitations, and other factors related to integration with other subsystems not directly involved with M&FM such as telemetry packing and processing. The baseline plan for use of VMET encompasses testing the original M&FM algorithms coded in the same C++ language and state machine architectural concepts as that used by Flight Software. This enables the development of performance standards and test cases to characterize the M&FM algorithms and sets a benchmark from which to measure the effectiveness of M&FM algorithms performance in the FSW development and test processes.

Trevino, Luis↗

NASA NTRS2015

A Vehicle Management End-to-End Testing and Analysis Platform for Validation of Mission and Fault Management Algorithms to Reduce Risk for NASAs Space Launch System

The engineering development of the National Aeronautics and Space Administration's (NASA) new Space Launch System (SLS) requires cross discipline teams with extensive knowledge of launch vehicle subsystems, information theory, and autonomous algorithms dealing with all operations from pre-launch through on orbit operations. The nominal and off-nominal characteristics of SLS's elements and subsystems must be understood and matched with the autonomous algorithm monitoring and mitigation capabilities for accurate control and response to abnormal conditions throughout all vehicle mission flight phases, including precipitating safing actions and crew aborts. This presents a large and complex systems engineering challenge, which is being addressed in part by focusing on the specific subsystems involved in the handling of off-nominal mission and fault tolerance with response management. Using traditional model-based system and software engineering design principles from the Unified Modeling Language (UML) and Systems Modeling Language (SysML), the Mission and Fault Management (M&FM) algorithms for the vehicle are crafted and vetted in Integrated Development Teams (IDTs) composed of multiple development disciplines such as Systems Engineering (SE), Flight Software (FSW), Safety and Mission Assurance (S&MA) and the major subsystems and vehicle elements such as Main Propulsion Systems (MPS), boosters, avionics, Guidance, Navigation, and Control (GNC), Thrust Vector Control (TVC), and liquid engines. These model-based algorithms and their development lifecycle from inception through FSW certification are an important focus of SLS's development effort to further ensure reliable detection and response to off-nominal vehicle states during all phases of vehicle operation from pre-launch through end of flight. To test and validate these M&FM algorithms a dedicated test-bed was developed for full Vehicle Management End-to-End Testing (VMET). For addressing fault management (FM) early in the development lifecycle for the SLS program, NASA formed the M&FM team as part of the Integrated Systems Health Management and Automation Branch under the Spacecraft Vehicle Systems Department at the Marshall Space Flight Center (MSFC). To support the development of the FM algorithms, the VMET developed by the M&FM team provides the ability to integrate the algorithms, perform test cases, and integrate vendor-supplied physics-based launch vehicle (LV) subsystem models. Additionally, the team has developed processes for implementing and validating the M&FM algorithms for concept validation and risk reduction. The flexibility of the VMET capabilities enables thorough testing of the M&FM algorithms by providing configurable suites of both nominal and off-nominal test cases to validate the developed algorithms utilizing actual subsystem models such as MPS, GNC, and others. One of the principal functions of VMET is to validate the M&FM algorithms and substantiate them with performance baselines for each of the target vehicle subsystems in an independent platform exterior to the flight software test and validation processes. In any software development process there is inherent risk in the interpretation and implementation of concepts from requirements and test cases into flight software compounded with potential human errors throughout the development and regression testing lifecycle. Risk reduction is addressed by the M&FM group but in particular by the Analysis Team working with other organizations such as S&MA, Structures and Environments, GNC, Orion, Crew Office, Flight Operations, and Ground Operations by assessing performance of the M&FM algorithms in terms of their ability to reduce Loss of Mission (LOM) and Loss of Crew (LOC) probabilities. In addition, through state machine and diagnostic modeling, analysis efforts investigate a broader suite of failure effects and associated detection and responses to be tested in VMET to ensure reliable failure detection, and confirm responses do not create additional risks or cause undesired states through interactive dynamic effects with other algorithms and systems. VMET further contributes to risk reduction by prototyping and exercising the M&FM algorithms early in their implementation and without any inherent hindrances such as meeting FSW processor scheduling constraints due to their target platform - the ARINC 6535-partitioned Operating System, resource limitations, and other factors related to integration with other subsystems not directly involved with M&FM such as telemetry packing and processing. The baseline plan for use of VMET encompasses testing the original M&FM algorithms coded in the same C++ language and state machine architectural concepts as that used by FSW. This enables the development of performance standards and test cases to characterize the M&FM algorithms and sets a benchmark from which to measure their effectiveness and performance in the exterior FSW development and test processes. This paper is outlined in a systematic fashion analogous to a lifecycle process flow for engineering development of algorithms into software and testing. Section I describes the NASA SLS M&FM context, presenting the current infrastructure, leading principles, methods, and participants. Section II defines the testing philosophy of the M&FM algorithms as related to VMET followed by section III, which presents the modeling methods of the algorithms to be tested and validated in VMET. Its details are then further presented in section IV followed by Section V presenting integration, test status, and state analysis. Finally, section VI addresses the summary and forward directions followed by the appendices presenting relevant information on terminology and documentation.

Trevino, Luis↗

NASA NTRSDate not supplied

A Notional Artemis Lunar Surface Exploration Package (ArLSEP) based on the Gandalf Staff Platform

Introduction: The Artemis program is planning to deliver crew and cargo to the lunar surface, but there is no current package for supporting lunar in-struments and experiments similar to the Apollo Lunar Surface Exploration Package (ALSEP). This abstract provides a possible concept for such a package using the Gandalf Staff Platform as a common core. Gandalf Staff: The Gandalf Staff is an early prototype system developed over FY’21/FY’22 using NASA Science Technology Mission Directorate (STMD) Center Information Fund (CIF) grants to de-sign, build and test “proof-of-concept” components. These components include a 24v battery powered monopole that powers a suite of subsystems, including a Graphical User Interface (GUI) for crew, surface voice and data communications, Lunar Search and Rescue (LunaSAR) navigation and communications, LiDAR, field site external lighting, 360-degree camera, and a geothermal instrument for measuring sub-surface temperature gradient. The staff can be carried independently by an Extra-Vehicular Activity (EVA) astronaut, or can be mounted into a tripod for “hands free” support at a surface site being investigated. The staff can be attached to an external solar array and power storage system for long-duration operations. [1,2] ALSEP: An ASLEP flew on each mission Apollo 12 to Apollo 17. For Apollo 11, a simplified packaged called the Early Apollo Scientific Experiments Pack-age (EASEP) was flown. Each package included a “Central Station” that provided the power and communications connected to a variety of instruments and sensors. The power was provided by a Radioisotope Thermoelectric Generator (RTG) fueled by Plutoni-um-238 generating 70 watts of power (initially, decayed over time) [3]. The communications system provide for direct to Earth data transfer from the lunar surface. Each pack-age was stowed externally in the Lunar Module (LM) Scientific Equipment (SEQ) bay with a mass up to 163 kg (Apollo 17). The crew unloaded the ALSEP from the LM and deployed the instruments on the lunar surface. Although designed to operate for only 1 year, many sites operated for up to 8 years successfully [4]. The Active Seismic Experiment (ASE) included 3 geophones for detecting seismic waves created by mortars and thumpers deployed by the crew. Other active experiments measured the lunar atmosphere, the heat flow in the subsurface, the lunar gravity and potential gravity waves, the lunar magnetic field, the solar wind and plasma interactions in cislunar space. Passive experiments included collectors for dust and cosmic rays, and retroreflectors for precise measurements of distance using a laser from Earth. The ALSEP program continues to generate insights into lunar formation and evolution. ArLSEP Concepts: The lunar surface science package for the Artemis program will hopefully exceed the capability of the ALSEP. There are multiple issues for discussion leading to the design of a new ArLSEP, needing requirements definition from the science community, NASA mission architecture, and NASA budget planners. 1. Delivery Mechanism Two possible projects currently provide capability to deliver scientific cargo to the lunar surface: 1) the Commercial Lunar Payload Services (CLPS) [5] and the Human Landing System (HLS) [6, 7]. Each project is controlled by a different organization within NASA and budgeted with different criteria although both support lunar exploration. The HLS system delivers crew (and potentially cargo) to human landing sites. If an ArLSEP is “predeployed” to such a site, the design must include power (either from the vehicle or independently) to keep the electronics functioning until deployed by the crew. If an ArLSEP is delivered on a vehicle after the crew is present on the lunar surface, safety protocols require adequate distance from the humans for impact from descent propelled sur-face regolith ejecta. This distance can not exceed the capability of the crew to walk (if no rover) to the vehicle for ArLSEP deployment. 2. Overall Guidelines The general design of ArLSEP will likely follow the ALSEP with a common system for communications and power; however, significant architecture differences between Apollo and Artemis exist. Power: The RTG will not be available for early Artemis missions nor likely follow-on Lunar Exploration Transportation Services (LETS) missions [8]. Thus, ArLSEP power must be supplied by solar arrays with sufficient battery capability to “keep alive” necessary electronics during any lunar surface eclipse period. Communication: The Artemis program is developing a series of communications satellites for lunar orbit to provide surface transmission of data and voice to Earth. Called “LunaNET”, this network is component useful for ArLSEP since south polar locations may not always have direct “line-of-sight” to Earth [9]. 3. Concept of Operations (ConOps) The general ConOps for ArLSEP is to deliver the package to lunar surface before the crew arrives, and then have the crew deploy the package after some period of time. This requires coordinated design (for power systems) and launch window (for schedule) on both the cargo and crew missions. Once the ArLSEP is deployed, it will operate autonomously for a number of years. It should be designed to be EVA compatible for crew maintenance and upgrade. 4. Notional Design (for discussion purpose only) The landing site near the South Pole is expected to have no eclipse cycle exceeding 5 days, so the “keep alive” power is 144 hours (6 days to include margin). A 12v ArLSEP will use rechargeable LiFePO4 cells, which are common in the Electric Vehicle (EV) industry. With a current of 5 amps and a 125 watt system, the mass is about 90kg. The comm. system and structure adds another 10kg, thus the “Central Station” is approximately 100kg. The solar power is collected on four arrays (each 2m above the surface), and the entire ArLSEP is designed to stow in a 2m x 1m x 1m volume. The experiment and instrument design will vary for each installation and add mass to the total (although they are expected to fit within the 2m3 volume). Seismic wave generation will likely not be provided with mortars, thus an electric “thumper” will be required. Active instruments such as imaging systems and sensing instruments will benefit from the additional power and communication capability provided by ArLSEP. Passive systems such as retroreflectors, witness plates, and cosmic dust collectors can be added to either the landing vehicle and/or the ArLSEP. With repeated HLS missions to the same human site, the ArLSEP can be expanded and easily maintained for long duration science collection on the lunar surface.

ALSEP↗