Search NASA⌕ Search

SEARCH · Search NASA

Results for “product lifecycle management”

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.

69 records · Page 4
All sourcesNASA NTRSDOE OSTI
NASA NTRS2020

Integrated Concurrent Engineering Teams for Increased Efficiency in Flight Projects

A highly integrated Concurrent Engineering Team (CET) within a flight project evolves in its function and has the potential to provide many benefits through the project lifecycle. The benefits include superior systems-oriented design products, as well as overall improved project efficiency and higher-performing interpersonal relationships within the project. If physically integrated, this can manifest as a Concurrent Engineering Center (CEC) centrally located within a project’s physical office space. Here we discuss the process to establish and maintain a tightly integrated engineering and design team for providing highly streamlined service to the project, including a cost/benefits analysis discussion.

Flight Project↗
NASA NTRSDate not supplied

Capturing, Analyzing, Maintaining, and Disseminating Shape Memory Material Data Between Information Management Systems

With an increased demand on reducing the time, cost, and effort to develop new materials, Integrated Computational Materials Engineering (ICME) has received widespread attention in various engineering disciplines as a catalyst for significantly reducing experimental testing during the material design process. An ICME approach to design can enable ‘fit-for-purpose’ materials to be realized in engineering applications by incorporating well-understood process-property-performance relationships between the various length and time scales in a material’s structure, enabling material optimization. However, such an approach requires validated multiscale models at the various length scales for a material, which in turn requires a large amount of data, a robust means of storing the data, and the ability to link data to developed material models. The NASA Vision 2040 [1] has identified nine key elements to enabling ICME approaches in system level design, with one being “Data, Information, and Visualization”, thus outlining the importance of a robust information management system for ICME. As the relationship between microstructure, properties, and material performance become better understood and incorporated into multiscale models that can be leveraged in application design, the emergence of new materials with application-driven properties can be realized. One such new material class that has seen growing attention are shape memory materials (SMM), in which a material can transition between a deformed and undeformed state via a reversible phase transformation when subject to a thermal, mechanical, or magnetic load [2]. SMMs have been used widely in aerospace and biomedical industries, including applications such as actuators, low-shock mechanisms, medical staples, braces, and stents [3, 4]. These materials exhibit unique behavior due to their ability to transition between phases, and thus the mechanisms that enable this transition must be captured in a data information management system and incorporated into SMM material models. At NASA Glenn Research Center, the Shape Memory Materials Database (SMMD) Tool has been developed to capture the necessary information that governs SMM material behavior and provide users the ability to select and visualize various SMMs for a specific application [5]. The database contains point-wise data for published SMM materials, along with the pedigree metadata for traceability necessary for a robust information management system. The database is also capable of storing in-house test data performed at NASA GRC by interacting with the developed Shape Memory Alloy (SMA) Analytics tool to extract the necessary point-wise values and populate the database. Although the SMMD Tool offers its users a single, authoritative source for SMM material data that is critical for model development and material design, the full material pedigree of the in-house test data for SMMs is not currently captured and is out of the scope for the SMMD tool. In this work, the schema for capturing SMM test data within the larger NASA GRC ICME Schema [6, 7, 8, 9] will be developed and implemented for thermomechanical tests conducted at NASA GRC. The developed schema will not only store the relevant data needed for the SMMD tool, but also the material pedigree (i.e., production of the bulk material, bulk material analysis, sample cut-out diagrams, sample fabrication procedure, etc.), test pedigree (i.e., test equipment used, measurement systems used, raw test data), and analysis pedigree (i.e., how the data in the SMMD tool is calculated). Furthermore, a Python-based framework will be developed to seamlessly interact between the SMA Analytics and SMMD tools, which will write the full dataset and associated metadata to the GRC Information Management System before passing the required point-wise data to the SMMD tool. Data informatics is a key element of the NASA Vision 2040, which requires not only that data is stored and maintained throughout the material lifecycle, but that the data is also accessible and reusable such that material development efforts can be minimized. Therefore, for an ICME design approach to be realized, a centralized information management system that drives the ICME process must be able to communicate with other databases. The work that will be presented in this presentation will therefore not only demonstrate the ability of NASA GRC’s information management system to capture SMM data, but also its ability to interact with pre-existing tools specialized for such materials.

Data management↗
NASA NTRS2022

Assurance Equations: A Cost and Criticality Model for Optimizing Quality Assurance Surveillance

The cost of quality vs cost of failure correction has been a long-running topic of discussion within the Aerospace community. It leads directly to concepts of “risk tolerance”, and risk-based decision-making. It would be valuable if there was a way to compute the optimal investment in customer-executed quality assurance activities using defect significance with respect to performance objectives, the activities’ defect detection effectiveness, and the cost-penalty for late discovery of impactful defects. This optimization is particularly of interest to projects whose budget constraints significantly limit their risk management options.The cost to fix defects (i.e., failure correction) escalates as the project matures. There have been studies attempting to determine the relative cost of fixing defects discovered during various phases of a project life cycle with important implications, all of which suggest growth factors are large. The commonly referred to 1:10:100 rule represents a cost multiplier for repair/rework across the Design to Fab to Test hardware development phases. Cost premiums for QA activities also accumulate when they are treated as mandatory (due to schedule drag) or are performed later than their assigned phase.This paper describes the modeling of development phase -dependencies in the conduct of typical customer-executed quality assurance activities. Our initial modeling encompasses:• Distinct phases of the production lifecycle• Multiple kinds of Defects, each with some a-priori likelihood of being present• Each defect’s impact on performance Objectives for a type of hardware• The cost and efficacy of assurance techniques at detecting such Defects• The costs of fixing those Defects detected in a given phase of the production lifecycleThe model captures assurance activities’ abilities to Detect defects. Upon detection it is assumed that the Defect is immediately fixed. Defects that “escape” detection by some activity may thereafter be detected by a later activity, but by then the cost of fixing the Defect may have escalated. Defects are related to the performance Objectives they would detract from, were those Defects to remain present in the operating system.We have constructed and are exploring, a model that relates the importance of hardware system elements to mission objectives, the impact of types of Defects on those hardware types, the cost of customer-executed assurance activities (i.e., supplier controls) and their effectiveness towards reducing an impactful quality escape, and the cost of Defect correction across production phase. We describe the approach taken to select the key model aspects, why they are relevant to our NASA mission, and our efforts to populate it with relevant and contemporary data. We use a notional example to illustrate model design and function.

Plante, Jeannette↗
NASA NTRSDate not supplied

Managing HRP’S External Deliverables: The Process and the Customers

The Human Research Program’s (HRP) external deliverables (EDs) are the final outcomes of the research that the HRP Elements develop and execute. Four categories of HRP EDs exist: standards, requirements, countermeasures, and tools/technology. The NASA Human Health and Performance directorate’s primary stakeholders, i.e., the customers for the EDs, include the Office of the Chief Health and Medical Officer (OCHMO) (Standards Team, Chief Health and Performance Officers and Chief Medical Officers, Human System Risk Board), and the agency’s System Capability Leadership Teams. The EDs may address the need of a specific customer, a specific design reference mission, or a vehicle lifecycle milestone. HRP’s Maturation and Integration Office External Programs facilitates the process of delivering the EDs to the targeted customers according to the customer’s expectations. This presentation describes this coordinated process and provides an overview of the nature of different types of EDs and how they impact the customers’ products. Successful transfer of the EDs to the customers will help mitigate the health and performance risks that crewmembers will face during NASA’s future exploration missions.

HRP research external deliverables↗
NASA NTRS2008

Modifying the Heliophysics Data Policy to Better Enable Heliophysics Research

The Heliophysics (HP) Science Data Management Policy, adopted by HP in June 2007, has helped to provide a structure for the HP data lifecycle. It provides guidelines for Project Data Management Plans and related documents, initiates Resident Archives to maintain data services after a mission ends, and outlines a route to the unification of data finding, access, and distribution through Virtual observatories. Recently we have filled in missing pieces that assure more coherence and a home for the VxOs (through the 'Heliophsyics Data and Model Consortium'), and provide greater clarity with respect to long term archiving. In particular, the new policy which has been vetted with many community members, details the 'Final Archives' that are to provide long-term data access. These are distinguished from RAs in that they provide little additional service beyond servicing data, but critical to their success is that the final archival materials include calibrated data in useful formats such as one finds in CDAWeb and various ASCII or FITS archives. Having a clear goal for legacy products, to be detailed as part of the Mission Archives Plans presented at Senior Reviews, will help to avoid the situation so common in the past of having archival products that preserve bits well but not readily usable information. We hope to avoid the need for the large numbers of 'data upgrade' projects that have been necessary in recent years.

Hayes, Jeffrey↗
NASA NTRS2017

Applying Standard Independent Verification and Validation (IVV) Techniques Within an Agile Framework: Is There a Compatibility Issue?

Agile methods have gained wide acceptance over the past several years, to the point that they are now a standard management and execution approach for small-scale software development projects. While conventional Agile methods are not generally applicable to large multi-year and mission-critical systems, Agile hybrids are now being developed (such as SAFe) to exploit the productivity improvements of Agile while retaining the necessary process rigor and coordination needs of these projects. From the perspective of Independent Verification and Validation (IVV), however, the adoption of these hybrid Agile frameworks is becoming somewhat problematic. Hence, we find it prudent to question the compatibility of conventional IVV techniques with (hybrid) Agile practices.This paper documents our investigation of (a) relevant literature, (b) the modification and adoption of Agile frameworks to accommodate the development of large scale, mission critical systems, and (c) the compatibility of standard IVV techniques within hybrid Agile development frameworks. Specific to the latter, we found that the IVV methods employed within a hybrid Agile process can be divided into three groups: (1) early lifecycle IVV techniques that are fully compatible with the hybrid lifecycles, (2) IVV techniques that focus on tracing requirements, test objectives, etc. are somewhat incompatible, but can be tailored with a modest effort, and (3) IVV techniques involving an assessment requiring artifact completeness that are simply not compatible with hybrid Agile processes, e.g., those that assume complete requirement specification early in the development lifecycle.

Agile↗
NASA NTRS2004

Transitioning to Intel-based Linux Servers in the Payload Operations Integration Center

The MSFC Payload Operations Integration Center (POIC) is the focal point for International Space Station (ISS) payload operations. The POIC contains the facilities, hardware, software and communication interface necessary to support payload operations. ISS ground system support for processing and display of real-time spacecraft and telemetry and command data has been operational for several years. The hardware components were reaching end of life and vendor costs were increasing while ISS budgets were becoming severely constrained. Therefore it has been necessary to migrate the Unix portions of our ground systems to commodity priced Intel-based Linux servers. hardware architecture including networks, data storage, and highly available resources. This paper will concentrate on the Linux migration implementation for the software portion of our ground system. The migration began with 3.5 million lines of code running on Unix platforms with separate servers for telemetry, command, Payload information management systems, web, system control, remote server interface and databases. The Intel-based system is scheduled to be available for initial operational use by August 2004 The overall migration to Intel-based Linux servers in the control center involves changes to the This paper will address the Linux migration study approach including the proof of concept, criticality of customer buy-in and importance of beginning with POSlX compliant code. It will focus on the development approach explaining the software lifecycle. Other aspects of development will be covered including phased implementation, interim milestones and metrics measurements and reporting mechanisms. This paper will also address the testing approach covering all levels of testing including development, development integration, IV&V, user beta testing and acceptance testing. Test results including performance numbers compared with Unix servers will be included. need for a smooth transition while maintaining real-time support. An important aspect of the paper will involve challenges and lessons learned. product compatibility, implications of phasing decisions and tracking of dependencies, particularly non- software dependencies. The paper will also discuss scheduling challenges providing real-time flight support during the migration and the requirement to incorporate in the migration changes being made simultaneously for flight support. This paper will also address the deployment approach including user involvement in testing and the , This includes COTS product compatibility, implications of phasing decisions and tracking of dependencies, particularly non- software dependencies. The paper will also discuss scheduling challenges providing real-time flight support during the migration and the requirement to incorporate in the migration changes being made simultaneously for flight support.

Guillebeau, P. L.↗
NASA NTRS2005

Failure Assessment

Three questions to which software developers want accurate, precise answers are "How can the software system fail?", "mat bad things will happen if the software fails?t', and "How many failures will the software experience?". Numerous techniques have been devised to answer these questions; three of the best known are: 1) Software Fault Tree Analysis (SFTA) 2) Software Failure Modes, Effects, and Criticality Analysis (SFMECA 3) Software Fault/Failure Modeling. SFTA and SFMECA have been successfully used to analyze the flight software for a number of robotic planetary exploration missions, including Galileo, Cassini, and Deep Space 1. Given the increasing interest in reusing software components from mission to mission, one of us has developed techniques for reusing the corresponding portions of the SFTA and SFMECA, reducing the effort required to conduct these analyses. SFTA has also been shown to be effective in analyzing the security aspects of software systems; intrusion mechanisms and effects can easily be modeled using these techniques. The Bi- Directional Safety Analysis (BDSA) method combines a forward search (similar to SFMECA) from potential failure modes to their effects, with a backward search (similar to SFTA) from feasible hazards to the contributing causes of each hazard. BDSA offers an efficient way to identify latent failures. Recent work has extended BDSA to product-line applications such as flight-instrumentation displays and developed tool support for the reuse of the failure-analysis artifacts within a product line. BDSA has also been streamlined to support those projects having tight cost and/or schedule constraints for their failure analysis efforts. We discuss lessons learned from practice, describe available tools, and identi@ some future directions for the topic. A substantial amount of research has been devoted to estimating the number of failures that a software system will experience during test and operations, as well as the number of faults that have been inserted into that system during its development. One of us has found that the amount of structural change to a system during its development is strongly related to the number of faults inserted into it. Using techniques requiring no additional effort on the part of the development organization, the required measurements of structural evolution can be easily obtained from a development effort's configuration management system and readily transformed into an estimate of fault content. So far, structure-fault relationships have been identified for source code; current work seeks to examine artifacts available earlier in the lifecycle to determine if similar relationships between structure and fault content can be found. In particular, relationships between requirements change requests and the number of faults inserted into the implemented system would provide a significant improvement in our ability to control software quality during the early development phases.

fault tree↗
NASA NTRSDate not supplied

An Overview of NASA’s Airborne and Field Data Resource Center

A key recommendation from NASA’s 2022 Airborne and Field Data Workshop called for the development of a virtual Resource Center for all stakeholders across the data lifecycle of airborne and field Earth observations. The agency’s Earth Science Data and Information System (ESDIS) Project and Airborne Data Management Group (ADMG) have worked in concert to establish the newly launched NASA Airborne and Field Data Resource Center (AFDRC) to provide a single entry point for a wide assortment of information on and the effective, responsible stewardship of non-satellite observational data. The AFDRC compiles access to many existing resources, but does so in a newly organized way that integrates availability to increase efficiency and holistic understanding while simplifying users’ experience. Initially launched in fall of 2023, the AFDRC is a NASA Earthdata domain website that clarifies several previously disparate resources and provides newly updated information, including: Learning Resources: Educational resources to broaden understanding of the role airborne and field observations play in advancing understanding of our planet and NASA’s role in collecting and archiving these data. Support for data users to Find and Access Data: Advanced contextual browse/search capabilities that efficiently link researchers to data products suitable for their science objectives - this includes linking to NASA’s Catalog of Archived Suborbital Earth Science Investigations (CASEI). Working with Data: Tools specific to individual types of suborbital Earth Science data and their (inter-)disciplinary communities to provide access as well as guidance for their application. Stewardship Responsibilities: Resources for data producers with to lessen requirement burdens at the time of data transfer, and information for data stewards with consistent, authoritative guidance on best practices and agency- and/or community- specific archival procedures. This presentation will give an overview of the motivation for NASA’s AFDRC, approach for the design and content, iterative community-driven improvements, promote the use of the AFDRC, and solicit additional feedback from airborne and field data user communities.

Sara Lubkin↗
NASA NTRS2018

Achieving Improved Reliability with Failure Analysis

Reliability is the ability of a product to properly function, within specified performance limits, for a specified period of time, under the life cycle application conditions. Failure analysis is a vital tool in the effort to ensure reliability of electronic products and systems throughout their product lifecycle. Today, organizations involved in activities within the electronics supply chain are facing new challenges, not just from complex assembly styles, harsher lifecycle environments, and sophisticated supply chains, but also from customers who are demanding a quicker turn-around. Unfortunately, root cause failure analysis is often performed incompletely, leading to a poor understanding of failure mechanisms and causes and, customer dissatisfaction due to recurring failures. The PDC starts with an introduction to reliability concepts, physics of failure and an overview of failure mechanisms that affect PCBs, PCBAs and components. The PDC then dives into root cause hypothesizing techniques (Pareto, FMEA, fishbone, FTA), non-destructive and destructive analysis and, materials characterization will be discussed. Numerous failure analysis case studies will be used to illustrate the techniques and analysis principles to arrive at the root cause(s) of field failures on printed circuit boards, active components, and assemblies. What Will You Learn: Topics include: Overview of Reliability Concepts Failure mechanisms of electronic products Root cause analysis Failure analysis techniques -Non-destructive techniques (optical, CSAM etc.) -Destructive analysis (DPA, Decap, FIB etc.) -Materials characterization (XRF, EDS, TMA/DSC etc.) Who Will Benefit: Reliability engineers, failure analysis engineers, engineering managers, design engineers, component engineers, quality assurance functions and, personnel involved with reliability activities within their company.

non-destructive techniques↗
NASA NTRS2011

Full-Scaled Advanced Systems Testbed: Ensuring Success of Adaptive Control Research Through Project Lifecycle Risk Mitigation

The National Aeronautics and Space Administration's Dryden Flight Research Center completed flight testing of adaptive controls research on the Full-Scale Advance Systems Testbed (FAST) in January of 2011. The research addressed technical challenges involved with reducing risk in an increasingly complex and dynamic national airspace. Specific challenges lie with the development of validated, multidisciplinary, integrated aircraft control design tools and techniques to enable safe flight in the presence of adverse conditions such as structural damage, control surface failures, or aerodynamic upsets. The testbed is an F-18 aircraft serving as a full-scale vehicle to test and validate adaptive flight control research and lends a significant confidence to the development, maturation, and acceptance process of incorporating adaptive control laws into follow-on research and the operational environment. The experimental systems integrated into FAST were designed to allow for flexible yet safe flight test evaluation and validation of modern adaptive control technologies and revolve around two major hardware upgrades: the modification of Production Support Flight Control Computers (PSFCC) and integration of two, fourth-generation Airborne Research Test Systems (ARTS). Post-hardware integration verification and validation provided the foundation for safe flight test of Nonlinear Dynamic Inversion and Model Reference Aircraft Control adaptive control law experiments. To ensure success of flight in terms of cost, schedule, and test results, emphasis on risk management was incorporated into early stages of design and flight test planning and continued through the execution of each flight test mission. Specific consideration was made to incorporate safety features within the hardware and software to alleviate user demands as well as into test processes and training to reduce human factor impacts to safe and successful flight test. This paper describes the research configuration, experiment functionality, overall risk mitigation, flight test approach and results, and lessons learned of adaptive controls research of the Full-Scale Advanced Systems Testbed.

Pavlock, Kate M.↗
NASA NTRS2011

Ground Processing Affordability for Space Vehicles

Launch vehicles and most of their payloads spend the majority of their time on the ground. The cost of ground operations is very high. So, why so often is so little attention given to ground processing during development? The current global space industry and economic environment are driving more need for efficiencies to save time and money. Affordability and sustainability are more important now than ever. We can not continue to treat space vehicles as mere science projects. More RLV's (Reusable Launch Vehicles) are being developed for the gains of reusability which are not available for ELV's (Expendable Launch Vehicles). More human-rated vehicles are being developed, with the retirement of the Space Shuttles, and for a new global space race, yet these cost more than the many unmanned vehicles of today. We can learn many lessons on affordability from RLV's. DFO (Design for Operations) considers ground operations during design, development, and manufacturing-before the first flight. This is often minimized for space vehicles, but is very important. Vehicles are designed for launch and mission operations. You will not be able to do it again if it is too slow or costly to get there. Many times, technology changes faster than space products such that what is launched includes outdated features, thus reducing competitiveness. Ground operations must be considered for the full product Lifecycle, from concept to retirement. Once manufactured, launch vehicles along with their payloads and launch systems require a long path of processing before launch. Initial assembly and testing always discover problems to address. A solid integration program is essential to minimize these impacts, as was seen in the Constellation Ares I-X test rocket. For RLV's, landing/recovery and post-flight turnaround activities are performed. Multi-use vehicles require reconfiguration. MRO (Maintenance, Repair, and Overhaul) must be well-planned--- even for the unplanned problems. Defect limits and standard repairs need to be in-place as well as easily added. Many routine inspections and maintenance can be like an aircraft overhaul. Modifications and technology upgrades should be expected. Another factor affecting ground operations efficiency is trending. It is essential for RLV's, and also useful for ELV's which fly the same or similar models again. Good data analysis of technical and processing performance will determine fixes and improvements needed for safety, design, and future processing. Collecting such data on new or low-frequency vehicles is a challenge. Lessons can be learned from the Space Shuttle, or even the Concorde aircraft. For all of the above topics, efficient business systems must be established for comprehensive program management and good throughput. Drawings, specifications, and manuals for an entire launch vehicle are often in different formats from multiple vendors, plus they have proprietary constraints. Nonetheless, the integration team must ensure that all data needed is compatible and visible to each appropriate team member. Ground processing systems for scheduling, tracking, problem resolution, etc. must be well laid-out. The balance between COTS (commercial off the shelf) and custom software is difficult. Multiple customers, vendors, launch sites, and landing sites add to the complexity of efficient IT (Information Technology) tools.

Ingalls, John↗
NASA NTRS2011

NASA Game Changing Development Program Manufacturing Innovation Project

This presentation examines the new NASA Manufacturing Innovation Project. The project is a part of the Game Changing Development Program which is one element of the Space Technology Programs Managed by Office of the Chief Technologist. The project includes innovative technologies in model-based manufacturing, digital additive manufacturing, and other next generation manufacturing tools. The project is also coupled with the larger federal initiatives in this area including the National Digital Engineering and Manufacturing Initiative and the Advanced Manufacturing Partnership. In addition to NASA, other interagency partners include the Department of Defense, Department of Commerce, NIST, Department of Energy, and the National Science Foundation. The development of game-changing manufacturing technologies are critical for NASA s mission of exploration, strengthening America s manufacturing competitiveness, and are highly related to current challenges in defense manufacturing activities. There is strong consensus across industry, academia, and government that the future competitiveness of U.S. industry will be determined, in large part, by a technologically advanced manufacturing sector. This presentation highlights the prospectus of next generation manufacturing technologies to the challenges faced NASA and by the Department of Defense. The project focuses on maturing innovative/high payoff model-based manufacturing technologies that may lead to entirely new approaches for a broad array of future NASA missions and solutions to significant national needs. Digital manufacturing and computer-integrated manufacturing "virtually" guarantee advantages in quality, speed, and cost and offer many long-term benefits across the entire product lifecycle. This paper addresses key enablers and emerging strategies in areas such as: Current government initiatives, Model-based manufacturing, and Additive manufacturing.

Tolbert, Carol↗
NASA NTRS2018

Collaborative Systems Engineering in the Ascent Abort-2 Crew Module/Separation Ring Project

Generally speaking, systems engineering (SE) tool-sets face a dilemma balancing power and accessibility. High-powered SE tools (MagicDraw, Cradle, Core, etc.) tend to be specialized and are available only to highly trained Systems Engineers, and/or through the use of a 'back room' developer team making the output products available to the broader team. On the other hand, highly accessible tools (MS Word, Excel, etc.) do not have the power to implement SE in a rigorous manner. NASA has to test all aspects of the new human-rated Orion Multi-Purpose Crew Vehicle spacecraft prior to its first crewed mission. The test program includes uncrewed launch abort flight tests to demonstrate the capability to save the crew in the event that a launch failure occurs. Orion's second abort flight test will be a low-altitude flight test known as "Ascent Abort 2 (AA-2)." This test is currently scheduled to be carried out at Cape Canaveral Air Force Station's Space Launch Complex 46 (SLC-46) in Florida in 2019. NASA's in-house AA-2 Crew Module and Separation Ring (CSR) Team is producing the crew module and separation ring. Operating jointly as both an Advanced Exploration Systems (AES) Project and an Orion Project, the CSR project charter includes development of innovative, streamlined and generally more efficient practices for creation of flight hardware and software. One result of this tasking has been development of a collaborative and data-centric systems engineering environment within the team's shared web environment (Microsoft SharePoint). Through the use of built-in, 'out of the box capabilities' present in MS SharePoint, the CSR Systems Engineering team has created (with some limited developer support) a data-centric architecture for the project's SE implementation, including functional and interface analysis, requirements development and management, risk management, verification planning and management, test results, and end item management. Data elements are linked between data structures so as to define and control relationships between item types, link requirements to parents and children, and link tests to the requirements that they verify. The overall project team integration is increased by also linking SE content to project management content over the project life cycle, including team communication, action items, configuration management, decisional and meeting materials, and life cycle reviews. This presentation will provide an overview of the collaborative SE environment, showing how it provides the power for a number of SE tasks while still providing the accessibility and transparency to allow the full project team to collaborate and succeed. Given the project phase, we'll be able to present a nearly full lifecycle discussion, from concept through verification and approaching delivery.

Systems Engineering environments↗
NASA NTRSDate not supplied

Uncrewed Lunar Surface Operations and Support Activities

Sustained human presence on the surface of the Moon and future missions to Mars require increased independence from surface crews and Earth-based mission control to operate efficiently, safely, and reliably. The time for surface crews to perform tasks will be limited. Extravehicular activities by surface personnel are burdensome and time-consuming, even when a continuous human presence on the surface occurs. Identifying and balancing human/automation roles and tasks and infusing automation and autonomy practices early in a system’s lifecycle will be essential to achieve mission objectives. Among these objectives are attaining a sustained human presence, improving performance and mission effectiveness, reducing operations and maintenance (O&M) costs, and ensuring operations that are robust to communication delays. To achieve these objectives, an operational shift toward increased automation and autonomy with less reliance on humans is needed. Uncrewed lunar surface operations and support activities occur when surface crews are not present or are independent of surface crew timeline activities requiring no surface crew oversight or intervention. These uncrewed surface opportunities can also be planned to minimize crew workload that avoids routine maintenance and support tasks, thus maximizing crew exploration time. Uncrewed preparations such as staging and prepositioning equipment and materials before the crew arrives could improve crew task efficiency. Additional opportunities exist to conduct uncrewed science, exploration, and utilization. Uncrewed surface architecture functions can include science and exploration; habitation; launch and landing support; surface communication and navigation; surface power generation and distribution; human surface mobility; lifting, handling, manipulating; excavation, construction, and site preparation; logistics management; maintenance and repair; surface resource utilization; integrated site operations and shared support services (e.g., site scheduling/prioritization, dust mitigation/contamination control, and surface safety). Early robotic lunar surface campaigns will provide information on the availability of resources, such as oxygen and water, and demonstrate surface-based technologies. After the Artemis III human lunar return mission, a series of landers will deliver surface systems, cargo, supplies, science packages, spare parts, and commodities. A balance of crewed and uncrewed surface operations will enable a sustained lunar surface presence at the South Pole of the Moon at a site that will be known as the Artemis Base Camp (ABC). It is envisioned that base camp operations on and around the Moon will then help prepare for the mission durations and activities needed to support the first human mission to Mars. Before long-duration crew missions to the base camp can occur, the necessary surface infrastructure will be pre-deployed and verified operational. Surface assets will be teleoperated and remotely managed from Earth. Additionally, robotic and short-duration crewed missions to the ABC will ensure the site’s merit to achieve long-term science objectives, availability of usable resources, and that terrain, seasonal variations, and illumination conditions are acceptable. ABC will consist of different areas where specific functions and services are rendered, including: • Launch and Landing Area • Habitation Area • Power Production Area • Resource Areas Launch and Landing Area—The launch and landing area will support associated functions for the arrival and departure of vehicles, such as crewed landing and ascent and uncrewed cargo deliveries and offloading. It will evolve from an unimproved site at the beginning of the exploration campaign to a more sustainable landing and launch area that can support repeated arrivals and departures. Initial uncrewed Lunar Terrain Vehicle (LTV) surface operations may include emplacement of navigation beacons and communication equipment, real-time video and photography of landing/liftoff events, and element repositioning, such as portable utility power (PUP) (applicable for other landed assets at other areas). Site preparations, such as surface leveling, soil compaction, and berm/path construction, may be needed for a more sustainable launch and landing area capable of accommodating vehicles that are increasingly more reusable and reduce the effects of plume surface interactions and ejecta impacts on nearby surface assets. During the ABC missions, cargo and logistics will be delivered to the lunar surface via robotic cargo landers before the crew arrives. These shipments, which can arrive in pressurized logistics carriers, will deliver the logistics necessary to support a crewed mission and include items such as food, water, equipment spares, etc. Providing the capability to retrieve, offload, and transport the logistics closer to the ABC site before the arrival of the crew will increase the overall efficiency of crew operations once they arrive. In the sustained phase of exploration, other supporting services may be needed, such as lander propellant servicing, surface power services, commodity refreshes, and additional inspection, maintenance, and repair capabilities, to sustain a cadence of extended personnel stays and cargo arrivals and departures. Habitation Area—Uncrewed support to surface habitation could involve supporting activation and pre-entry operations of the habitat while the crew is in orbit at the Gateway outpost preparing for a surface landing. Surface Habitat (SH) uncrewed operations may include bringing the cabin environment to a habitable temperature and air mix and activating other critical crew support systems. Potential crop production uncrewed tasks in the SH could also include autonomous watering and tending. Additionally, when the crew departs, the SH enters dormancy for the long period of uncrewed operation. A logistical staging area could also be collocated near the SH. If so, staging operations for crew supplies, waste re-location, and recycling operations may be opportunities for uncrewed operations. Power Production Area—The Fission Surface Power (FSP) element and its supporting distribution equipment provide power to surface elements as needed across the ABC to supplement day-to-day operations and survive lunar nights. Uncrewed support of this power system includes any initial LTV-assisted deployments of cables and other distributed equipment, associated electrical connections, and system testing and activation operations. Robotically performing some inspections, maintenance, or repair tasks on the power distribution equipment could reduce the surface crew workload. Resource Area— Uncrewed resource prospecting, mapping, and characterizing possible resource sites is likely to be time-consuming and represents an opportunity for uncrewed operations between crewed missions. Uncrewed mobile equipment operations will be needed in the extreme environments of permanently shadowed locations where resource extractions occur. As In-Situ Resource Utilization (ISRU) pilot plant operations begin, uncrewed surface support activities with available mobile and portable assets (LTV, PUP, etc.) will better support these operations. Any produced commodities can be stored at a centralized storage location for future use. Also associated with these operations is the use of mobile robotic excavators for resource acquisition and robotic/autonomous regolith processing. The waste tailings generated during excavation and regolith processing would also need to be transported and deposited at a dedicated location. Surface assets will continue operating between crew visits to maintain surface capabilities, conduct lunar surface science, technology demonstrations, and public outreach opportunities. Additionally, certain sustaining tasks that would consume valuable crew time could be performed before crew arrival, or after their departure. This capability may offer more affordable options to construct, activate, test, and maintain a broad set of surface assets. Telerobotically operated human surface mobility systems, such as the LTV and Pressurized Rover (PR), can be utilized for various tasks. Surface environmental conditions pose a distinct challenge for all these activities. Surface illumination and localized shadows are one such factor. Night-survival operations could consist of thermal management, battery pre-charging, and load shedding. Some surface systems may hibernate through the night and then awake and continue nominal operations. Uncrewed mobile assets may use a more adaptive approach to optimize their power and operations; one method is to follow the sunlight. Night-survival operations may be initiated remotely by teleoperation, automated, or accomplished by supervised autonomous operation. The ability to pre-deploy and control remote assets in orbit or on Mars before the arrival of the mission crew is a key capability that can be simulated on the moon. The base camp provides a venue where these advanced operational concepts, technologies, and autonomous methods and techniques, including the incorporation of time delays to simulate Earth-Mars latency can be replicated to help buy down future Mars mission risks. This paper will examine the evolution of uncrewed lunar surface operations and support activities. It will also discuss the lunar surface environmental conditions (thermal, lighting, terrain, topography, communications) along with the challenges they pose on uncrewed surface operations, and the performance of these activities with limited to minimal human interaction and/or teleoperation. Since lunar missions include Mars mission analogs, such investigation provides the framework for future uncrewed Mars mission support.

Mark E Lewis↗