Search NASA⌕ Search

SEARCH · Search NASA

Results for “software lifecycle”

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.

196 records · Page 11
All sourcesNASA NTRSDOE OSTI
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 NTRS2017

Mars 2020 Model Based Systems Engineering Pilot

The pilot study is led by the Integration Engineering group in NASA's Launch Services Program (LSP). The Integration Engineering (IE) group is responsible for managing the interfaces between the spacecraft and launch vehicle. This pilot investigates the utility of Model-Based Systems Engineering (MBSE) with respect to managing and verifying interface requirements. The main objectives of the pilot are to model several key aspects of the Mars 2020 integrated operations and interface requirements based on the design and verification artifacts from Mars Science Laboratory (MSL) and to demonstrate how MBSE could be used by LSP to gain further insight on the interface between the spacecraft and launch vehicle as well as to enhance how LSP manages the launch service. The method used to accomplish this pilot started through familiarization of SysML, MagicDraw, and the Mars 2020 and MSL systems through books, tutorials, and NASA documentation. MSL was chosen as the focus of the model since its processes and verifications translate easily to the Mars 2020 mission. The study was further focused by modeling specialized systems and processes within MSL in order to demonstrate the utility of MBSE for the rest of the mission. The systems chosen were the In-Flight Disconnect (IFD) system and the Mass Properties process. The IFD was chosen as a system of focus since it is an interface between the spacecraft and launch vehicle which can demonstrate the usefulness of MBSE from a system perspective. The Mass Properties process was chosen as a process of focus since the verifications for mass properties occur throughout the lifecycle and can demonstrate the usefulness of MBSE from a multi-discipline perspective. Several iterations of both perspectives have been modeled and evaluated. While the pilot study will continue for another 2 weeks, pros and cons of using MBSE for LSP IE have been identified. A pro of using MBSE includes an integrated view of the disciplines, requirements, and verifications leading up to launch. The model allows IE to understand the relationships between disciplines throughout test activities and verifications. Additionally, the relationships between disciplines and integration tasks are generally consistent. The model allows for the generic relationships and tasks to be captured and used throughout multiple mission models should LSP further pursue MBSE. A con of MBSE is the amount of time it takes upfront to understand MBSE and create a useful model. The upfront time it takes to create a useful model is heavily discussed in MBSE literature and is a consistent con throughout the known applications of MBSE. The need to understand SysML and the software chosen also poses the possibility of a "bottleneck" or one person being the sole MBSE user for the working group. The utility of MBSE will continue to be evaluated through the remainder of the study. In conclusion, the original objectives of the pilot study were to use artifacts from MSL to model key aspects of Mars 2020 and demonstrate how MBSE could be used by LSP to gain insight into the spacecraft and launch vehicle interfaces. Progress has been made in modeling and identifying the utility of MBSE to LSP IE and will continue to be made until the pilot study's conclusion in mid-August. The results of this study will produce initial models, modeling instructions and examples, and a summary of MBSE's utility for future use by LSP.

Dukes, Alexandra Marie↗
NASA NTRSDate not supplied

Preservation of Provenance and Context to Ensure Future Understandability of Airborne Earth Observations and Derived Data Products

Open-source science goes beyond making data from scientific projects (e.g., on-orbit/satellite missions, airborne and field investigations, and other data producing activities) openly available after they are generated, but involves and open sharing of information throughout the project lifecycle. Preservation of the data and associated information required for understanding and reusing the data well after the scientific projects is a contributor to open-source science as well. Considering the high investment in the on-orbit/satellite missions, we had developed a document titled “NASA Earth Science Data Preservation Content Specification (PCS)” in 2011. This document has been used as a requirement for recent on-orbit/satellite missions by NASA. Recently it became clear that the specifications should be applied to other scientific projects as well. Therefore, the document was revised to cover other types of projects, and a Preservation Content Implementation Guidance (PCIG) document was also developed. The revised PCS, and the PCIG, were published in 2022. The purpose of this presentation is to highlight the contents of these documents as they apply to suborbital/airborne investigations. The PCS calls for content preservation in eight general categories - Measuring Instrument/Platform Description, Instrument and Science Data Products and Metadata, Science Raw Data, Product and Algorithm Documentation, Instrument Calibration, Science Algorithm Software, Science Data Product Algorithm Inputs, Science Data Product Validation, and Science Data Access and Analysis Tools. While all these categories apply to various types of projects, a few clarifying sentences have been added to the descriptions of contents in each of the categories to show which categories are especially important to airborne and field investigations and where some contents are not applicable (or difficult to obtain). The PCIG document provides some general guidance applicable to all types of projects and specific guidance in a separate section for airborne and field investigations. This section calls out typical artifacts produced during such investigations that can meet the spirit of the various PCS categories.

remote sensing↗
DOE OSTI2025

DEMographic MicrOSimulation (DEMOS) v2.0

DEMOS is an agent-based simulation framework used to evolve population demographic characteristics or lifecycle events such as education, marital status etc. DEMOS modules are designed to capture the interdependencies of short-term and long-term lifecycle events often influential in downstream transportation and land use modeling. An important facet of DEMOS is that it is dynamic, meaning it captures the impact of an agent's demographic characteristics in year 't' on their demographic status in year 't+1'. This has important consequences on medium- and long-term downstream modeling in different domains, such as transportation where decisions such as household vehicle transactions (i.e., buying, selling, or replacing a vehicle) depend current or past household vehicle holdings as well as household transitions. Other downstream modeling that can be enabled by DEMOS include building technology adoption or retrofit decisions, and more. DEMOS modules include: individual age progression year by year, individual mortality events, household restructuring events including marriage match-making; household birth events; individual education participation; individual labor force participation; child leaving household; household in-migration and out-migration for the region; household residence location choice and household mandatory destination choice (work and school). This version of DEMOS is tailored to be integrated with the land use simulation software UrbanSim.

Caicedo, Juan [UrbanSim, Inc.]↗
DOE OSTI2021

Recommendations for Distributed Energy Resource Patching

While computer systems, software applications, and operational technology (OT)/Industrial Control System (ICS) devices are regularly updated through automated and manual processes, there are several unique challenges associated with distributed energy resource (DER) patching. Millions of DER devices from dozens of vendors have been deployed in home, corporate, and utility network environments that may or may not be internet-connected. These devices make up a growing portion of the electric power critical infrastructure system and are expected to operate for decades. During that operational period, it is anticipated that critical and noncritical firmware patches will be regularly created to improve DER functional capabilities or repair security deficiencies in the equipment. The SunSpec/Sandia DER Cybersecurity Workgroup created a Patching Subgroup to investigate appropriate recommendations for the DER patching, holding fortnightly meetings for more than nine months. The group focused on DER equipment, but the observations and recommendations contained in this report also apply to DERMS tools and other OT equipment used in the end-to-end DER communication environment. The group found there were many standards and guides that discuss firmware lifecycles, patch and asset management, and code-signing implementations, but did not singularly cover the needs of the DER industry. This report collates best practices from these standards organizations and establishes a set of best practices that may be used as a basis for future national or international patching guides or standards.

97 MATHEMATICS AND COMPUTING↗
NASA NTRS2016

Towards a Methodology and Tooling for Model-Based Probabilistic Risk Assessment (PRA)

A Probabilistic Risk Assessment (PRA) aims to identify and assess potential risks to system technical performance requirements for the purpose of furnishing risk insights into project decisions. PRAs have traditionally been conducted manually using software with an isolated data model. As system complexity rises it becomes difficult to ensure consistency between a PRA, the evolving system design, and other engineering analyses; the techniques for conducting PRAs must evolve to meet this challenge. This work presents progress towards a methodology and tooling for conducting a PRA by leveraging data in the system model, embedded for other purposes and analyses, to conduct a PRA. An approach for identifying the appropriate probabilistic equation for each risk scenario from a standard library is presented, which is a significant step towards the quantification of the likelihood of a risk scenario occurrence. The final calculation of the likelihood of occurrence is left as an item of future work. We also present the development of preliminary tooling to carry out the methodology on a well-formed system model. The information needed to conduct the PRA is embedded in a consistent manner in a system model, so the model-based PRA can be regularly executed as the system model changes. The ability to modify the PRA in concert with lifecycle evolution affords a project the opportunity to track the extent to which system modification impacts compliance with requirements. These aspects of this model-based PRA methodology make it capable of managing risk in increasingly complex technical systems.

Schreiner, Samuel S.↗
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 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 NTRS2016

JPL's Foundry Furnace: Web-Based Concurrent Engineering for Formulation

The Jet Propulsion Laboratory’s Innovation Foundry is an enterprise tasked with shepherding space mission concepts through the formulation lifecycle. It oversees a number of “virtual teams” for the various stages of formulation. Among these is Team X, which has had considerable success over its more than 20-year history. In a Team X study, domain experts (including engineers devoted to the various spacecraft subsystems) work concurrently and collaboratively over several days to arrive at a feasible point design with a reasonable cost estimate. They use a set of linked Excel workbooks, each developed and approved by a responsible “line organization” within JPL. This toolset has served Team X well over the years, and has evolved since its inception. At the same time, the Innovation Foundry’s portfolio of formulation teams has expanded, and so has the scope of the design challenges they face. The A-Team runs workshop-like architecture studies to focus science investigations, generate mission concepts, assess feasibility, and explore trade spaces. Team Xc performs rapid point design in the style of Team X, but for CubeSats and small spacecraft, using a different toolset. Proposal teams further mature concepts to the point where they can be proposed. Recognizing the importance of trade space modeling combined with new IT services for providing and integrating data, JPL is developing the Foundry Furnace web-based software infrastructure. It will support A-Team, Team Xc, and Team X, providing study management, a catalog of hardware components, a library of re-usable analyses, and a design environment. It is a modernization of JPL’s concurrent engineering infrastructure, embracing the core concepts of Model-Based Systems Engineering, and built with modern software design philosophies.

Murphy, Jonathan↗
NASA NTRS2016

MarCO: Interplanetary Mission Development on a CubeSat Scale

Shortly after JPL’s Interior Exploration using Seismic Investigations, Geodesy and Heat Transport (InSight) mission launches, separates, and commences its cruise phase, two CubeSats will deploy from the launch vehicle’s upper stage and begin independent flight to Mars (Fig. 1). During InSight’s entry, descent, and landing (EDL) sequence, these twin Mars Cube One (MarCO) spacecraft will fly 3,500 km above the Martian surface, recording and relaying InSight UHF radio data to the Deep Space Network (DSN) on Earth1. MarCO is a twin CubeSat mission developed by the NASA Jet Propulsion Laboratory (JPL) to accompany the InSight (Interior Exploration using Seismic Investigations, Geodesy and Heat Transport) Mars mission lander. MarCO's primary mission objective is to launch with InSight and independently fly to Mars to serve as a communications relay during InSight's entry, descent, and landing (EDL) phase. MarCO represents a new type of deep space mission: CubeSats at Mars. Building on the development of JPL's first interplanetary CubeSat project, the Interplanetary Nano-Spacecraft Pathfinder in Relevant Environment (INSPIRE), MarCO further refined the approach to hardware, software, and ground architecture development to solve the challenges of quickly building low-budget spacecraft to fly to Mars. The greatest constraint, beyond others typical of CubeSat missions, was time. The duration between MarCO's conception to completion of spacecraft assembly was less than two years - an unprecedented schedule for any planetary mission to date. Through necessity, MarCO has built on previous experience, procedures, systems, and development methodologies, defining a new niche for supporting larger primary missions. The MarCO spacecraft are poised to write a new chapter in deep space exploration. Originally slated to launch and reach Mars in 2016, the InSight mission schedule subsequently slipped to 2018. During the original landing of InSight, Earth would not be in view, and no orbiter around Mars would have been in position to both receive UHF EDL data and simultaneously relay it back to Earth. It was from this obstacle that MarCO was conceived. Regardless of any changes to InSight’s 2018 EDL configuration geometry, MarCO is still expected to fly and serve in the same capacity as originally designed: the first CubeSat mission to Mars. CubeSats have historically been firmly in the domain of universities and small companies. As first conceived, they served as a platform upon which to teach all aspects of the space mission lifecycle. JPL took on this mission type with Interplanetary Nano-Spacecraft Pathfinder in Relevant Environment2 (INSPIRE), moving the concept into a new domain: deep space. Building from the INSPIRE platform and lessons learned, MarCO addressed new challenges in the domain of planetary missions: independent interplanetary flight and navigation, integration with a large-scale mission, long-distance and long-delay communication, short development time, and a small development team. Of these, the greatest constraint was schedule: only 18 months passed from conception of mission concept until delivery of fully assembled and tested flight hardware. Careful selection of mission team, along with extensive use of off-the-shelf equipment, and streamlining automated processes, was essential. This achievement represents the next step in the evolution of CubeSats beyond low-Earth orbit.

Werne, Thomas↗
NASA NTRS2005

Integrated Systems Health Management for Space Exploration

Integrated Systems Health Management (ISHM) is a system engineering discipline that addresses the design, development, operation, and lifecycle management of components, subsystems, vehicles, and other operational systems with the purpose of maintaining nominal system behavior and function and assuring mission safety and effectiveness under off-nominal conditions. NASA missions are often conducted in extreme, unfamiliar environments of space, using unique experimental spacecraft. In these environments, off-nominal conditions can develop with the potential to rapidly escalate into mission- or life-threatening situations. Further, the high visibility of NASA missions means they are always characterized by extraordinary attention to safety. ISHM is a critical element of risk mitigation, mission safety, and mission assurance for exploration. ISHM enables: In-space maintenance and repair; a) Autonomous (and automated) launch abort and crew escape capability; b) Efficient testing and checkout of ground and flight systems; c) Monitoring and trending of ground and flight system operations and performance; d) Enhanced situational awareness and control for ground personnel and crew; e) Vehicle autonomy (self-sufficiency) in responding to off-nominal conditions during long-duration and distant exploration missions; f) In-space maintenance and repair; and g) Efficient ground processing of reusable systems. ISHM concepts and technologies may be applied to any complex engineered system such as transportation systems, orbital or planetary habitats, observatories, command and control systems, life support systems, safety-critical software, and even the health of flight crews. As an overarching design and operational principle implemented at the system-of-systems level, ISHM holds substantial promise in terms of affordability, safety, reliability, and effectiveness of space exploration missions.

Uckun, Serdar↗
DOE OSTI2020

On the Formalization of Development and Assessment Process for Digital Twins in the Nearly Autonomous Management and Control System

In recent years, the autonomous control system has been encouraged in advanced reactors for restoring economic viability, simplifying the operation and maintenance, and enabling remote-site power generations [1]. Since the reactor is expected to be operated for a long period of time with a limited number of individuals onsite, it is recommended that the autonomous control system should have access to very realistic models of the state of processes in the whole lifecycle, together with these process behaviors in interaction with their environment in the real world. As a result, digital twin (DT) technology is suggested in autonomous control systems. DT is defined as a digital representation of a physical object or system, which contains a record for the histories of loads, operation and maintenance status, predictions for the near-term transient of important state variables, and decision-making process [2]. Since machine learning (ML) can recognize patterns within a complex system in real-time applications, it has been used to build DTs in the autonomous control systems for advanced reactors. Meanwhile, due to the rareness of operation data in accident scenarios, the development and assessment of DTs is expected to be mainly driven by simulations. Although the capability and feasibility of ML-based DTs are recognized in improving the safety and efficiency of reactor control, a major concern from the regulatory commission and the nuclear industry is whether the information from a DT is developed and assessed in accordance with expectation and requirements by the target decision. Such concerns not only affect the acceptance criteria for DTs, but also values that can be extracted from DTs and autonomous control system during operations. Inspired by the success of formal methods in improving the reliability and robustness of computer programming and software development, it is suggested that the development and assessment process (DAP) for both separate DTs and integral control system should be formalized in a transparent, consistent, and improvable manner. In this study, a digital-twin development and assessment process (DT-DAP) is proposed by adapting the evaluation model development and assessment process (EMDAP) [3] to requirements by the autonomous control system, ML algorithms, and DT technology. To demonstrate the framework, a baseline nearly autonomous management and control (NAMAC) system with ML-based DTs for diagnosis and prognosis is developed and assessed based on the framework. It is found that with selected testing methods and techniques, the DT-DAP can help identify errors in DTs and NAMAC which would otherwise be left unverified. Meanwhile, it is found that the DT-DAP can improve the DTs and NAMAC by continuously learning and iterating through different elements.

22 GENERAL STUDIES OF NUCLEAR REACTORS↗
DOE OSTI2019

ROBOT: A Tool for Automating Ontology Workflows

BACKGROUND:Ontologies are invaluable in the life sciences, but building and maintaining ontologies often requires a challenging number of distinct tasks such as running automated reasoners and quality control checks, extracting dependencies and application-specific subsets, generating standard reports, and generating release files in multiple formats. Similar to more general software development, automation is the key to executing and managing these tasks effectively and to releasing more robust products in standard forms. For ontologies using the Web Ontology Language (OWL), the OWL API Java library is the foundation for a range of software tools, including the Protégé ontology editor. In the Open Biological and Biomedical Ontologies (OBO) community, we recognized the need to package a wide range of low-level OWL API functionality into a library of common higher-level operations and to make those operations available as a command-line tool. RESULTS:ROBOT (a recursive acronym for "ROBOT is an OBO Tool") is an open source library and command-line tool for automating ontology development tasks. The library can be called from any programming language that runs on the Java Virtual Machine (JVM). Most usage is through the command-line tool, which runs on macOS, Linux, and Windows. ROBOT provides ontology processing commands for a variety of tasks, including commands for converting formats, running a reasoner, creating import modules, running reports, and various other tasks. These commands can be combined into larger workflows using a separate task execution system such as GNU Make, and workflows can be automatically executed within continuous integration systems. CONCLUSIONS:ROBOT supports automation of a wide range of ontology development tasks, focusing on OBO conventions. It packages common high-level ontology development functionality into a convenient library, and makes it easy to configure, combine, and execute individual tasks in comprehensive, automated workflows. This helps ontology developers to efficiently create, maintain, and release high-quality ontologies, so that they can spend more time focusing on development tasks. It also helps guarantee that released ontologies are free of certain types of logical errors and conform to standard quality control checks, increasing the overall robustness and efficiency of the ontology development lifecycle.

96 KNOWLEDGE MANAGEMENT AND PRESERVATION↗
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 NTRS2012

Development of Human System Integration at NASA

Human Systems Integration seeks to design systems around the capabilities and limitations of the humans which use and interact with the system, ensuring greater efficiency of use, reduced error rates, and less rework in the design, manufacturing and operational deployment of hardware and software. One of the primary goals of HSI is to get the human factors practitioner involved early in the design process. In doing so, the aim is to reduce future budget costs and resources in redesign and training. By the preliminary design phase of a project nearly 80% of the total cost of the project is locked in. Potential design changes recommended by evaluations past this point will have little effect due to lack of funding or a huge cost in terms of resources to make changes. Three key concepts define an effective HSI program. First, systems are comprised of hardware, software, and the human, all of which operate within an environment. Too often, engineers and developers fail to consider the human capacity or requirements as part of the system. This leads to poor task allocation within the system. To promote ideal task allocation, it is critical that the human element be considered early in system development. Poor design, or designs that do not adequately consider the human component, could negatively affect physical or mental performance, as well as, social behavior. Second, successful HSI depends upon integration and collaboration of all the domains that represent acquisition efforts. Too often, these domains exist as independent disciplines due to the location of expertise within the service structure. Proper implementation of HSI through participation would help to integrate these domains and disciplines to leverage and apply their interdependencies to attain an optimal design. Via this process domain interests can be integrated to perform effective HSI through trade-offs and collaboration. This provides a common basis upon which to make knowledgeable decisions. Finally, HSI must be considered early in the requirements development phase of system design and acquisition. This will provide the best opportunity to maximize return on investment (ROI) and system performance. HSI requirements must be developed in conjunction with capability ]based requirements generation through functional. HSI requirements will drive HSI metrics and embed HSI issues within the system design. After a system is designed, implementation of HSI oversights can be very expensive. An HSI program should be included as an integral part of a total system approach to vehicle and habitat development. This would include, but not limited to, workstation design, D&C development, volumetric analysis, training, operations, and human -robotic interaction. HSI is a necessary process for Human Space Flight programs to meet the Agency Human ]System standards and thus mitigate human risks to acceptable levels. NASA has been involved in HSI planning, procedures development, process, and implementation for many years, and has been building several internal and publicly accessible products to facilitate HSI fs inclusion in the NASA Systems Engineering Lifecycle. Some of these products include: NASA STD 3001 Volumes 1 and 2, Human Integration Design Handbook, NASA HSI Implementation Plan, NASA HSI Implementation Plan Templates, NASA HSI Implementation Handbook, and a 2 ]hour short course on HSI delivered as part of the NASA Space and Life Sciences Directorate Academy. These products have been created leveraging industry best practices and lessons learned from other Federal Government agencies.

Whitmore, Mihriban↗
NASA NTRS2022

Event Report for The Ethical Artificial Intelligence Quantification Workshop

Artificial Intelligence (AI) is a powerful emerging technology area which requires special attention to using it ethically. AI ethics is still an emerging field, and the partners for this workshop and report seek to move AI ethics discussion ahead by experimenting with ways to measure AI ethics criteria. The following document describes the outcomes and learnings from The Ethical Artificial Intelligence Quantification Workshop held at the National Institute for Aerospace (NIA), Hampton, Virginia on May 12th, 2022. The purpose of the workshop was for participants to evaluate and experiment-with the methodology and process presented by AIEthics.World in cooperation with Intel Corporation. The meeting participants learned about the Ethical AI Certification and Maturity Model™ and applied the methodology to selected notional AI systems. The workshop facilitated the evaluation of the maturity of the AI system according to ethical considerations relevant to NASA, NIA and other participants. The workshop consisted of three main phases. The first phase focused on understanding and summarizing NASA’s ethical approaches, mission and values based on published documentation, discussions and individual insights & opinions of participants. This information was prioritized, weighted, ordered, and quantified in phase two, to formulate an alignment between human values (ethics) and their applicability to AI systems during all lifecycle phases. The first two phases were summarized as a form of ethical genealogy for artificial intelligence, specific to NASA’s ethical approaches. In the third and last phase of the workshop the participants evaluated notional examples of artificial intelligence to qualify and quantify its ability to adhere to the organizational ethics approaches, using the Ethical AI Certification and Maturity Model™. The workshop uses the concept of genealogy, in the traditional sense: the study and traceability of lines of ancestors in the process of evolutionary development from earlier forms. However, as it is applied to an Ethical AI definition, it is providing the insights to the necessary and mandatory traceability of content, data, metrics, telemetry, elements, and structures which are used in the AI’s lifecycle to foster and measure AI ethics in all steps of its lifecycle. The Ethical Artificial Intelligence Quantification Workshop provided NASA with the opportunity to apply the Ethical AI Certification and Maturity Model™, in combination with existing and well-known decision-making and quality control methods to identify the metrics and measurements for an Ethical AI and assess its ethical condition and quality aligned with NASA ethics approaches. The result of the workshop is the capacity for NASA to apply the maturity model assessment to its AI Systems as desired and if necessary, publish the ability of these AI Systems to adhere to the organizational ethical goals. AI ethics frameworks need to be customized for each application domain, for example, individual NASA Mission Directorates. General principles that work in one area such as AI/Machine Learning-based text analysis (the ethics of information-extraction) may need to be adapted for another such as sense-and-avoid decision-making in a flight environment. The workshop was conducted among approximately twenty NASA subject matter experts, so the elements noted above should be considered examples, not definitive NASA ethical AI principles, genealogy, etc. Generating a definitive AI ethics framework for an organization as diverse as NASA would require far more discussion, debate, review, etc. However, the workshop provided valuable insight into mechanisms and processes for quantifying AI ethical qualities.

Artificial Intelligence↗