SEARCH · Engineering Papers

Results for “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.

SourceResearch connectionFrom yearThrough year

Quote a phrase for an exact phrase match. Source license links do not imply unrestricted reuse.

At least 127 records · Page 7

All sources NASA NTRS DOE OSTI

NASA NTRS2004

Performance and Reliability Optimization for Aerospace Systems subject to Uncertainty and Degradation

This report summarizes work performed by the Space Systems Laboratory (SSL) for NASA Langley Research Center in the field of performance optimization for systems subject to uncertainty. The objective of the research is to develop design methods and tools to the aerospace vehicle design process which take into account lifecycle uncertainties. It recognizes that uncertainty between the predictions of integrated models and data collected from the system in its operational environment is unavoidable. Given the presence of uncertainty, the goal of this work is to develop means of identifying critical sources of uncertainty, and to combine these with the analytical tools used with integrated modeling. In this manner, system uncertainty analysis becomes part of the design process, and can motivate redesign. The specific program objectives were: 1. To incorporate uncertainty modeling, propagation and analysis into the integrated (controls, structures, payloads, disturbances, etc.) design process to derive the error bars associated with performance predictions. 2. To apply modern optimization tools to guide in the expenditure of funds in a way that most cost-effectively improves the lifecycle productivity of the system by enhancing the subsystem reliability and redundancy. The results from the second program objective are described. This report describes the work and results for the first objective: uncertainty modeling, propagation, and synthesis with integrated modeling.

Miller, David W.↗

NASA NTRS2005

Design Methods and Practices for Fault Prevention and Management in Spacecraft

Integrated Systems Health Management (ISHM) is intended to become a critical capability for all space, lunar and planetary exploration vehicles and systems at NASA. Monitoring and managing the health state of diverse components, subsystems, and systems is a difficult task that will become more challenging when implemented for long-term, evolving deployments. A key technical challenge will be to ensure that the ISHM technologies are reliable, effective, and low cost, resulting in turn in safe, reliable, and affordable missions. To ensure safety and reliability, ISHM functionality, decisions and knowledge have to be incorporated into the product lifecycle as early as possible, and ISHM must be considered as an essential element of models developed and used in various stages during system design. During early stage design, many decisions and tasks are still open, including sensor and measurement point selection, modeling and model-checking, diagnosis, signature and data fusion schemes, presenting the best opportunity to catch and prevent potential failures and anomalies in a cost-effective way. Using appropriate formal methods during early design, the design teams can systematically explore risks without committing to design decisions too early. However, the nature of ISHM knowledge and data is detailed, relying on high-fidelity, detailed models, whereas the earlier stages of the product lifecycle utilize low-fidelity, high-level models of systems and their functionality. We currently lack the tools and processes necessary for integrating ISHM into the vehicle system/subsystem design. As a result, most existing ISHM-like technologies are retrofits that were done after the system design was completed. It is very expensive, and sometimes futile, to retrofit a system health management capability into existing systems. Last-minute retrofits result in unreliable systems, ineffective solutions, and excessive costs (e.g., Space Shuttle TPS monitoring which was considered only after 110 flights and the Columbia disaster). High false alarm or false negative rates due to substandard implementations hurt the credibility of the ISHM discipline. This paper presents an overview of the current state of ISHM design,and a review of formal design methods to make recommendations about possible approaches to enable the ISHM capabilities to be designed-in at the system-level, from the very beginning of the vehicle design process.

Tumer, Irem Y.↗

NASA NTRS2006

System Architecture Modeling for Technology Portfolio Management using ATLAS

Strategic planners and technology portfolio managers have traditionally relied on consensus-based tools, such as Analytical Hierarchy Process (AHP) and Quality Function Deployment (QFD) in planning the funding of technology development. While useful to a certain extent, these tools are limited in the ability to fully quantify the impact of a technology choice on system mass, system reliability, project schedule, and lifecycle cost. The Advanced Technology Lifecycle Analysis System (ATLAS) aims to provide strategic planners a decision support tool for analyzing technology selections within a Space Exploration Architecture (SEA). Using ATLAS, strategic planners can select physics-based system models from a library, configure the systems with technologies and performance parameters, and plan the deployment of a SEA. Key parameters for current and future technologies have been collected from subject-matter experts and other documented sources in the Technology Tool Box (TTB). ATLAS can be used to compare the technical feasibility and economic viability of a set of technology choices for one SEA, and compare it against another set of technology choices or another SEA. System architecture modeling in ATLAS is a multi-step process. First, the modeler defines the system level requirements. Second, the modeler identifies technologies of interest whose impact on an SEA. Third, the system modeling team creates models of architecture elements (e.g. launch vehicles, in-space transfer vehicles, crew vehicles) if they are not already in the model library. Finally, the architecture modeler develops a script for the ATLAS tool to run, and the results for comparison are generated.

Thompson, Robert W.↗

NASA NTRS2007

NASA's Software Safety Standard

NASA relies more and more on software to control, monitor, and verify its safety critical systems, facilities and operations. Since the 1960's there has hardly been a spacecraft launched that does not have a computer on board that will provide command and control services. There have been recent incidents where software has played a role in high-profile mission failures and hazardous incidents. For example, the Mars Orbiter, Mars Polar Lander, the DART (Demonstration of Autonomous Rendezvous Technology), and MER (Mars Exploration Rover) Spirit anomalies were all caused or contributed to by software. The Mission Control Centers for the Shuttle, ISS, and unmanned programs are highly dependant on software for data displays, analysis, and mission planning. Despite this growing dependence on software control and monitoring, there has been little to no consistent application of software safety practices and methodology to NASA's projects with safety critical software. Meanwhile, academia and private industry have been stepping forward with procedures and standards for safety critical systems and software, for example Dr. Nancy Leveson's book Safeware: System Safety and Computers. The NASA Software Safety Standard, originally published in 1997, was widely ignored due to its complexity and poor organization. It also focused on concepts rather than definite procedural requirements organized around a software project lifecycle. Led by NASA Headquarters Office of Safety and Mission Assurance, the NASA Software Safety Standard has recently undergone a significant update. This new standard provides the procedures and guidelines for evaluating a project for safety criticality and then lays out the minimum project lifecycle requirements to assure the software is created, operated, and maintained in the safest possible manner. This update of the standard clearly delineates the minimum set of software safety requirements for a project without detailing the implementation for those requirements. This allows the projects leeway to meet these requirements in many forms that best suit a particular project's needs and safety risk. In other words, it tells the project what to do, not how to do it. This update also incorporated advances in the state of the practice of software safety from academia and private industry. It addresses some of the more common issues now facing software developers in the NASA environment such as the use of Commercial-Off-the-Shelf Software (COTS), Modified OTS (MOTS), Government OTS (GOTS), and reused software. A team from across NASA developed the update and it has had both NASA-wide internal reviews by software engineering, quality, safety, and project management. It has also had expert external review. This presentation and paper will discuss the new NASA Software Safety Standard, its organization, and key features. It will start with a brief discussion of some NASA mission failures and incidents that had software as one of their root causes. It will then give a brief overview of the NASA Software Safety Process. This will include an overview of the key personnel responsibilities and functions that must be performed for safety-critical software.

Ramsay, Christopher M.↗

NASA NTRS2004

Virtual Mission Operation Framework (VMOF)

The Virtual Mission Operation Framework (VMOF) is one of the project lifecycle engineering process improvement efforts initiated by the institutional technology infrastructure program at JPL. The VMOF is composed of three frameworks: a model integration framework, a simulation framework, and a visualization framework. The model integration framework interfaces with spacecraft system design, mission design, and structure design. The simulation framework interfaces with the operation scenario design, environmental phenomena science, and science payload system design. The visualization framework interfaces with the flight system testbed, the ground system, and the science analysis. The three frameworks of the VMOF collaborate to create a comprehensive virtual mission operation that enables a "validation-in-the-loop" system design process and lifecycle-continuous science-return validation.This paper discusses the technical approaches for each framework implementation, challenges and approaches involved in streamlining mission information access, and on-going activities toward enabling Model-Based Engineering Design in a collaborative distributed environment.

virtual mission operations↗

NASA NTRS2008

Human Factors in Human-Systems Integration

Any large organization whose mission is to design and develop systems for humans, and train humans needs a well-developed integration and process plan to deal with the challenges that arise from managing multiple subsystems. Human capabilities, skills, and needs must be considered early in the design and development process, and must be continuously considered throughout the development lifecycle. This integration of human needs within system design is typically formalized through a Human-Systems Integration (HSI) program. By having an HSI program, an institution or organization can reduce lifecycle costs and increase the efficiency, usability, and quality of its products because human needs have been considered from the beginning.

Fitts, David J.↗

NASA NTRS2008

Problem Reporting System

The Problem Reporting System (PRS) is a Web application, running on two Web servers (load-balanced) and two database servers (RAID-5), which establishes a system for submission, editing, and sharing of reports to manage risk assessment of anomalies identified in NASA's flight projects. PRS consolidates diverse anomaly-reporting systems, maintains a rich database set, and incorporates a robust engine, which allows tracking of any hardware, software, or paper process by configuring an appropriate life cycle. Global and specific project administration and setup tools allow lifecycle tailoring, along with customizable controls for user, e-mail, notifications, and more. PRS is accessible via the World Wide Web for authorized user at most any location. Upon successful log-in, the user receives a customizable window, which displays time-critical 'To Do' items (anomalies requiring the user s input before the system moves the anomaly to the next phase of the lifecycle), anomalies originated by the user, anomalies the user has addressed, and custom queries that can be saved for future use. Access controls exist depending on a user's role as system administrator, project administrator, user, or developer, and then, further by association with user, project, subsystem, company, or item with provisions for business-to-business exclusions, limitations on access according to the covert or overt nature of a given project, all with multiple layers of filtration, as needed. Reporting of metrics is built in. There is a provision for proxy access (in which the user may choose to grant one or more other users to view screens and perform actions as though they were the user, during any part of a tracking life cycle - especially useful during tight build schedules and vacations to keep things moving). The system also provides users the ability to have an anomaly link to or notify other systems, including QA Inspection Reports, Safety, GIDEP (Government-Industry Data Exchange Program) Alert, Corrective Actions, and Lessons Learned. The PRS tracking engine was designed as a very extensible and scalable system, able to support additional applications, with future development possibilities already discussed, including Incident Surprise Anomalies (for anomalies occurring during Operations phases of NASA Flight projects), GIDEP and NASA Alerts, and others.

Potter, Don↗

NASA NTRS2010

Assessing Requirements Volatility and Risk Using Bayesian Networks

There are many factors that affect the level of requirements volatility a system experiences over its lifecycle and the risk that volatility imparts. Improper requirements generation, undocumented user expectations, conflicting design decisions, and anticipated / unanticipated world states are representative of these volatility factors. Combined, these volatility factors can increase programmatic risk and adversely affect successful system development. This paper proposes that a Bayesian Network can be used to support reasonable judgments concerning the most likely sources and types of requirements volatility a developing system will experience prior to starting development and by doing so it is possible to predict the level of requirements volatility the system will experience over its lifecycle. This assessment offers valuable insight to the system's developers, particularly by providing a starting point for risk mitigation planning and execution.

Russell, Michael S.↗

NASA NTRS2011

Data Service Provider Cost Estimation Tool

The Data Service Provider Cost Estimation Tool (CET) and Comparables Database (CDB) package provides to NASA s Earth Science Enterprise (ESE) the ability to estimate the full range of year-by-year lifecycle cost estimates for the implementation and operation of data service providers required by ESE to support its science and applications programs. The CET can make estimates dealing with staffing costs, supplies, facility costs, network services, hardware and maintenance, commercial off-the-shelf (COTS) software licenses, software development and sustaining engineering, and the changes in costs that result from changes in workload. Data Service Providers may be stand-alone or embedded in flight projects, field campaigns, research or applications projects, or other activities. The CET and CDB package employs a cost-estimation-by-analogy approach. It is based on a new, general data service provider reference model that provides a framework for construction of a database by describing existing data service providers that are analogs (or comparables) to planned, new ESE data service providers. The CET implements the staff effort and cost estimation algorithms that access the CDB and generates the lifecycle cost estimate for a new data services provider. This data creates a common basis for an ESE proposal evaluator for considering projected data service provider costs.

Fontaine, Kathy↗

NASA NTRS2006

NASA Crew Launch Vehicle Approach Builds on Lessons from Past and Present Missions

The United States Vision for Space Exploration, announced in January 2004, outlines the National Aeronautics and Space Administration's (NASA) strategic goals and objectives, including retiring the Space Shuttle and replacing it with a new human-rated system suitable for missions to the Moon and Mars. The Crew Exploration Vehicle (CEV) that the new Crew Launch Vehicle (CLV) lofts into space early next decade will initially ferry astronauts to the International Space Station and be capable of carrying crews back to lunar orbit and of supporting missions to Mars orbit. NASA is using its extensive experience gained from past and ongoing launch vehicle programs to maximize the CLV system design approach, with the objective of reducing total lifecycle costs through operational efficiencies. To provide in-depth data for selecting this follow-on launch vehicle, the Exploration Systems Architecture Study was conducted during the summer of 2005, following the confirmation of the new NASA Administrator. A team of aerospace subject matter experts used technical, budget, and schedule objectives to analyze a number of potential launch systems, with a focus on human rating for exploration missions. The results showed that a variant of the Space Shuttle, utilizing the reusable Solid Rocket Booster as the first stage, along with a new upper stage that uses a derivative of the RS-25 Space Shuttle Main Engine to deliver 25 metric tons to low-Earth orbit, was the best choice to reduce the risks associated with fielding a new system in a timely manner. The CLV Project, managed by the Exploration Launch Office located at NASA's Marshall Space Flight Center, is leading the design, development, testing, and operation of this new human-rated system. The CLV Project works closely with the Space Shuttle Program to transition hardware, infrastructure, and workforce assets to the new launch system . leveraging a wealth of lessons learned from Shuttle operations. The CL V is being designed to reduce costs through a number of methods, ranging from validating requirements to conducting trades studies against the concept design. Innovations such as automated processing will build on lessons learned from the Shuttle, other launch systems, Department of Defense operations experience, and subscale flight tests such as the Delta Clipper-Experimental Advanced (DCXA) vehicle operations that utilized minimal touch labor, automated cryogen ic propellant loading , and an 8-hour turnaround for a cryogenic propulsion system. For the CLV, the results of hazard analyses are contributing to an integrated vehicle health monitoring system that will troubleshoot anomalies and determine which ones can be solved without human intervention. Such advances will help streamline the mission operations process for pilots and ground controllers alike. In fiscal year 2005, NASA invested approximately $4.5 billion of its $16 bill ion budget on the Space Shuttle. The ultimate goal of the CLV Project is to deliver a safe, reliable system designed to minimize lifecycle costs so that NASA's budget can be invested in missions of scientific discovery. Lessons learned from developing the CLV will be applied to the growth path for future systems, including a heavy lift launch vehicle.

Dumbacher, Daniel L.↗

NASA NTRS2012

Integrating Existing Simulation Components into a Cohesive Simulation System

A tradition of leveraging the re-use of components to help manage costs has evolved in the development of complex system. This tradition continues on in the Joint Polar Satellite System (JPSS) Program with the cloning of the Suomi National Polar-orbiting Partnership (NPP) satellite for the JPSS-1 mission, including the instrument complement. One benefit of re-use on a mission is the availability of existing simulation assets from the systems that were previously built. An issue arises in the continual shift of technology over a long mission, or multi-mission, lifecycle. As the missions mature, the requirements for the observatory simulations evolve. The challenge in this environment becomes re-using the existing components in that ever-changing landscape. To meet this challenge, the system must: establish an operational architecture that minimizes impacts on the implementation of individual components, consolidate the satisfaction of new high-impact requirements into system-level infrastructure, and build in a long-term view of system adaptation that spans the full lifecycle of the simulation system. The Flight Vehicle Test Suite (FVTS) within the JPSS Program is defining and executing this approach to ensure a robust simulation capability for the JPSS multi-mission environment

McLaughlin, Brian J.↗

NASA NTRS2012

Modular, Autonomous Command and Data Handling Software with Built-In Simulation and Test

The spacecraft system that plays the greatest role throughout the program lifecycle is the Command and Data Handling System (C&DH), along with the associated algorithms and software. The C&DH takes on this role as cost driver because it is the brains of the spacecraft and is the element of the system that is primarily responsible for the integration and interoperability of all spacecraft subsystems. During design and development, many activities associated with mission design, system engineering, and subsystem development result in products that are directly supported by the C&DH, such as interfaces, algorithms, flight software (FSW), and parameter sets. A modular system architecture has been developed that provides a means for rapid spacecraft assembly, test, and integration. This modular C&DH software architecture, which can be targeted and adapted to a wide variety of spacecraft architectures, payloads, and mission requirements, eliminates the current practice of rewriting the spacecraft software and test environment for every mission. This software allows missionspecific software and algorithms to be rapidly integrated and tested, significantly decreasing time involved in the software development cycle. Additionally, the FSW includes an Onboard Dynamic Simulation System (ODySSy) that allows the C&DH software to support rapid integration and test. With this solution, the C&DH software capabilities will encompass all phases of the spacecraft lifecycle. ODySSy is an on-board simulation capability built directly into the FSW that provides dynamic built-in test capabilities as soon as the FSW image is loaded onto the processor. It includes a six-degrees- of-freedom, high-fidelity simulation that allows complete closed-loop and hardware-in-the-loop testing of a spacecraft in a ground processing environment without any additional external stimuli. ODySSy can intercept and modify sensor inputs using mathematical sensor models, and can intercept and respond to actuator commands. ODySSy integration is unique in that it allows testing of actual mission sequences on the flight vehicle while the spacecraft is in various stages of assembly, test, and launch operations all without any external support equipment or simulators. The ODySSy component of the FSW significantly decreases the time required for integration and test by providing an automated, standardized, and modular approach to integrated avionics and component interface and functional verification. ODySSy further provides the capability for on-orbit support in the form of autonomous mission planning and fault protection.

Cuseo, John↗

NASA NTRS2008

Applied Space Systems Engineering: Manage Technical Data - Chapter 17

Effective space systems engineering (SSE) is conducted in a fully electronic manner. Competitive hardware, software, and system designs are created in a totally digital environment that enables rapid product design and manufacturing cycles, as well as a multitude of techniques such as modeling, simulation, and lean manufacturing that significantly reduce the lifecycle cost of systems. Because the SSE lifecycle depends on the digital environment, managing the enormous volumes of technical data needed to describe, build, deploy, and operate systems is a critical factor in the success of a project. This chapter presents the key aspects of Technical Data Management (TDM) within the SSE process. It is written from the perspective of the System Engineer tasked with establishing the TDM process and infrastructure for a major project. Additional perspectives are reflected from the point of view of the engineers on the project who work within the digital engineering environment established by the TDM toolset and infrastructure, and from the point of view of the contactors who interface via the TDM infrastructure. Table 17.1 lists the TDM process as it relates to SSE.

Kent, Peter↗

NASA NTRS2013

Workflow-Based Software Development Environment

The Software Developer's Assistant (SDA) helps software teams more efficiently and accurately conduct or execute software processes associated with NASA mission-critical software. SDA is a process enactment platform that guides software teams through project-specific standards, processes, and procedures. Software projects are decomposed into all of their required process steps or tasks, and each task is assigned to project personnel. SDA orchestrates the performance of work required to complete all process tasks in the correct sequence. The software then notifies team members when they may begin work on their assigned tasks and provides the tools, instructions, reference materials, and supportive artifacts that allow users to compliantly perform the work. A combination of technology components captures and enacts any software process use to support the software lifecycle. It creates an adaptive workflow environment that can be modified as needed. SDA achieves software process automation through a Business Process Management (BPM) approach to managing the software lifecycle for mission-critical projects. It contains five main parts: TieFlow (workflow engine), Business Rules (rules to alter process flow), Common Repository (storage for project artifacts, versions, history, schedules, etc.), SOA (interface to allow internal, GFE, or COTS tools integration), and the Web Portal Interface (collaborative web environment

Izygon, Michel E.↗

NASA NTRS2013

An Overview of Regional Experiments on Biomass Burning Aerosols and Related Pollutants in Southeast Asia: From BASE-ASIA and the Dongsha Experiment to 7-SEAS

By modulating the Earth-atmosphere energy, hydrological and biogeochemical cycles, and affecting regional-to-global weather and climate, biomass burning is recognized as one of the major factors affecting the global carbon cycle. However, few comprehensive and wide-ranging experiments have been conducted to characterize biomass-burning pollutants in Southeast Asia (SEA) or assess their regional impact on meteorology, the hydrological cycle, the radiative budget, or climate change. Recently, BASEASIA (Biomass-burning Aerosols in South-East Asia: Smoke Impact Assessment) and the 7-SEAS (7- South-East Asian Studies) Dongsha Experiment were conducted during the spring seasons of 2006 and 2010 in northern SEA, respectively, to characterize the chemical, physical, and radiative properties of biomass-burning emissions near the source regions, and assess their effects. This paper provides an overview of results from these two campaigns and related studies collected in this special issue, entitled Observation, modeling and impact studies of biomass burning and pollution in the SE Asian Environment. This volume includes 28 papers, which provide a synopsis of the experiments, regional weatherclimate, chemical characterization of biomass-burning aerosols and related pollutants in source and sink regions, the spatial distribution of air toxics (atmospheric mercury and dioxins) in source and remote areas, a characterization of aerosol physical, optical, and radiative properties, as well as modeling and impact studies. These studies, taken together, provide the first relatively complete dataset of aerosol chemistry and physical observations conducted in the sourcesink region in the northern SEA, with particular emphasis on the marine boundary layer and lower free troposphere (LFT). The data, analysis and modeling included in these papers advance our present knowledge of source characterization of biomass-burning pollutants near the source regions as well as the physical and chemical processes along transport pathways. In addition, we raise key questions to be addressed by a coming deployment during springtime 2013 in northern SEA, named 7-SEASBASELInE (Biomass-burning Aerosols Stratocumulus Environment: Lifecycles and Interactions Experiment). This campaign will include a synergistic approach for further exploring many key atmospheric processes (e.g., complex aerosol-cloud interactions) and impacts of biomass burning on the surface-atmosphere energy budgets during the lifecycles of biomass burning emissions.

aerosol/biomass burning↗

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 NTRS2016

Systems Engineering and Management Applications of ISO 9001:2015 for Government

The manufacturing segment of the business world is busy assessing the impact of ISO 9001:2015, and updating their management systems to meet the required compliance date. What does the new revision mean for government agencies that deliver large engineering projects rather than mass production? In fact, the standard, especially the new revision, can be used quite readily for government agencies, or applied to specific projects, once it is understood in terms of the similarities with systems engineering and project management. From there it can be extrapolated to "mission realization" systems, and a Quality Management System (QMS) is a logical result that can bring order to processes and systems that likely already exist in some fashion. ISO 9001:2015 is less product-oriented than previous versions. It can be more broadly applied to public organizations as well as private; and to services (missions) as well as products. The emphasis on risk management in the revised standard provides the needed balance for weighing decisions with respect to cost, schedule, technical, safety, and regulatory compliance; so if this is not part of agency governance already, this is a good place to start, especially for large engineering projects. The Systems Engineering standard used for this analysis is from NASA's NPR 7123.1 NASA Systems Engineering Processes and Requirements; however, those who are more familiar with ISO/IEC 26702 Systems Engineering-application and management of the systems engineering process, or SAE/EIA 632 Processes for Engineering a System will also recognize the similarities. In reality, the QMS outlined by ISO 9001 reinforces the systems engineering processes, and serves to ensure that they are adequately implemented, although most of the ISO 9001 literature emphasizes the production and process aspects of the standard. Rather than beginning with ISO 9001and getting lost in the vocabulary, it is useful to begin with the systems engineering lifecycle. Identification of stakeholder expectations, identifying solutions, creating specific product or service designs, production of the product or service, delivery to the public, and the associated management, planning, and control processes, are a familiar place to begin thinking of the overall system of identifying, designing, and competing a project or mission. Lining up this lifecycle with the ISO requirements (see Figure 1) illustrates how a quality management system is concerned with the same processes, and provides a governance and assurance function. If implemented properly, there are cost savings resulting from less rework, repair, reprocessing, failures, misplaced documents, and similar types of deficiencies1. Starting with an organization's systems engineering processes allows the organization to use their own terminology for a QMS plan, and tailor the plan to their own project or organization, so that it is more easily developed, understood, and implemented.

Shepherd, Christena C.↗

NASA NTRS2016

Promoting a Culture of Tailoring for Systems Engineering Policy Expectations

NASA's Marshall Space Flight Center (MSFC) has developed an integrated systems engineering approach to promote a culture of tailoring for program and project policy requirements. MSFC's culture encourages and supports tailoring, with an emphasis on risk-based decision making, for enhanced affordability and efficiency. MSFC's policy structure integrates the various Agency requirements into a single, streamlined implementation approach which serves as a "one-stop-shop" for our programs and projects to follow. The engineers gain an enhanced understanding of policy and technical expectations, as well as lesson's learned from MSFC's history of spaceflight and science missions, to enable them to make appropriate, risk-based tailoring recommendations. The tailoring approach utilizes a standard methodology to classify projects into predefined levels using selected mission and programmatic scaling factors related to risk tolerance. Policy requirements are then selectively applied and tailored, with appropriate rationale, and approved by the governing authorities, to support risk-informed decisions to achieve the desired cost and schedule efficiencies. The policy is further augmented by implementation tools and lifecycle planning aids which help promote and support the cultural shift toward more tailoring. The MSFC Customization Tool is an integrated spreadsheet that ties together everything that projects need to understand, navigate, and tailor the policy. It helps them classify their project, understand the intent of the requirements, determine their tailoring approach, and document the necessary governance approvals. It also helps them plan for and conduct technical reviews throughout the lifecycle. Policy tailoring is thus established as a normal part of project execution, with the tools provided to facilitate and enable the tailoring process. MSFC's approach to changing the culture emphasizes risk-based tailoring of policy to achieve increased flexibility, efficiency, and effectiveness in project execution, while maintaining appropriate rigor to ensure mission success.

Blankenship, Van A.↗