Engineering Papers⌕ Search

SEARCH · Engineering Papers

Results for “software defined infrastructure”

Search indexed NASA NTRS and DOE OSTI research on propulsion, heat transfer, battery materials and energy systems. Follow report and document links to the original sources.

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

At least 55 records · Page 3
All sourcesNASA NTRSDOE OSTI
NASA NTRS2017

Defining Medical Levels of Care for Exploration Missions

NASA medical care standards establish requirements for providing health and medical programs for crewmembers during all phases of a mission. These requirements are intended to prevent or mitigate negative health consequences of long-duration spaceflight, thereby optimizing crew health and performance over the course of the mission. Current standards are documented in the two volumes of the NASA-STD-3001 Space Flight Human-System Standard document, established by the Office of the Chief Health and Medical Officer. Its purpose is to provide uniform technical standards for the design, selection, and application of medical hardware, software, processes, procedures, practices, and methods for human-rated systems. NASA-STD-3001 Vol. 1 identifies five levels of care for human spaceflight. These levels of care are accompanied by several components that illustrate the type of medical care expected for each. The Exploration Medical Capability (ExMC) of the Human Research Program has expanded the context of these provided levels of care and components. This supplemental information includes definitions for each component of care and example actions that describe the type of capabilities that coincide with the definition. This interpretation is necessary in order to fully and systematically define the capabilities required for each level of care in order to define the medical requirements and plan for infrastructure needed for medical systems of future exploration missions, such as one to Mars.

Hailey, M.↗
NASA NTRS1990

An expert system for simulating electric loads aboard Space Station Freedom

Space Station Freedom will provide an infrastructure for space experimentation. This environment will feature regulated access to any resources required by an experiment. Automated systems are being developed to manage the electric power so that researchers can have the flexibility to modify their experiment plan for contingencies or for new opportunities. To define these flexible power management characteristics for Space Station Freedom, a simulation is required that captures the dynamic nature of space experimentation; namely, an investigator is allowed to restructure his experiment and to modify its execution. This changes the energy demands for the investigator's range of options. An expert system competent in the domain of cryogenic fluid management experimentation was developed. It will be used to help design and test automated power scheduling software for Freedom's electric power system. The expert system allows experiment planning and experiment simulation. The former evaluates experimental alternatives and offers advice on the details of the experiment's design. The latter provides a real-time simulation of the experiment replete with appropriate resource consumption.

Kukich, George↗
NASA NTRS1990

An expert system for simulating electric loads aboard Space Station Freedom

Space Station Freedom will provide an infrastructure for space experimentation. This environment will feature regulated access to any resources required by an experiment. Automated systems are being developed to manage the electric power so that researchers can have the flexibility to modify their experiment plan for contingencies or for new opportunities. To define these flexible power management characteristics for Space Station Freedom, a simulation is required that captures the dynamic nature of space experimentation; namely, an investigator is allowed to restructure his experiment and to modify its execution. This changes the energy demands for the investigator's range of options. An expert system competent in the domain of cryogenic fluid management experimentation, was developed. It will be used to help design and test automated power scheduling software for Freedom's electric power system. The expert system allows experiment planning and experiment simulation. The former evaluates experimental alternatives and offers advice on the details of the experiment's design. The latter provides a real-time simulation of the experiment replete with appropriate resource consumption.

Kukich, George↗
NASA NTRS2019

Cloud Computing Methods for Near Rectilinear Halo Orbit Trajectory Design

Complicated mission design problems require innovative computational solutions. As spacecraft depart from a proposed Gateway in a Near Rectilinear Halo Orbit (NRHO), recontact analysis is required to avoid risk of collision and ensure safe operations. Escape dynamics from NRHOs are governed by multiple gravitational bodies, yielding a trajectory design space that is exhaustively large. This paper summarizes the recontact analysis for departure from the NRHO and describes how the Deep Space Trajectory Explorer (DSTE) trajectory design software incorporates high performance cloud computing to compute and visualize the orbit design space. Recent focus on exploration missions to cislunar space has kindled accelerated interest in multibody orbit solutions. Trajectory analysis in the presence of multiple gravity fields is complex, and innovative computational tools are needed to simplify complicated design spaces, to generate large quantities of data quickly, and to visualize the output for user accessibility. The Gateway mission is a prime example. The Gateway1 is proposed as a human outpost in deep space. The current baseline orbit for the Gateway is a Near Rectilinear Halo Orbit (NRHO) near the Moon.2 The NRHO exists in a regime that experiences the gravitational effects of the Earth and the Moon simultaneously, complicating orbit analysis. The mission design process benefits greatly from updated computational tools for multibody missions like the Gateway. As an example, consider the problem of assessing the risk of collision in an NRHO. As a staging location to missions to the lunar surface and beyond the Earth-Moon system, the Gateway will experience spacecraft and other objects regularly arriving and departing. Departing objects potentially include spent logistics modules, visiting crew vehicles, debris objects, wastewater particles, and cubesats. Each departure is governed by the dynamics of the Gateway orbit and the surrounding dynamical environment. Over time, any unmaintained object in such an orbit eventually departs due to the small instabilities associated with the NRHOs. A separation maneuver speeds the departure from the NRHO, but the effects of the maneuver on the spacecraft behavior depend on the location, magnitude, and direction of the burn. Escape dynamics from the NRHO with regard to these maneuver options open up an enormous potential trajectory design space where subtle changes in input can produce dramatically large changes in the results. Any departing object must avoid recontacting the Gateway as it leaves the lunar vicinity, and a recontact analysis thus involves a significant number of computations and extensive output data. To explore the dynamics of this extensive design space, the Deep Space Trajectory Explorer3 (DSTE) trajectory design software incorporates new High Performance Computing (HPC) services and novel interactive visualizations. This paper details the HPC and cloud infrastructure techniques that are implemented in the DSTE, applying the new capabilities to analysis of recontact risk with the Gateway in NRHO. NEAR RECTILINEAR HALO ORBITS The Gateway is planned to fly in a lunar NRHO as its baseline orbit. The NRHO families of orbits are subsets of the larger halo families, which originate from planar orbits near the L1 and L2 libration points; the Earth-Moon L2 halo family appears in Figure 1. Each halo orbit is perfectly periodic in the Circular Restricted 3-Body Problem (CR3BP) and becomes a quasi-periodic orbit in a higher fidelity ephemeris force model. The NRHOs are defined as those members of the halo family with bounded stability properties;2 they pass near the Moon at perilune and are nearly polar. Families exist with apolunes located both above the lunar north pole and above the lunar south pole; the Gateway is planned to reside in a southern L2 NRHO in a 9:2 resonance with the lunar synodic period. The 9:2 NRHO is characterized by a period of about 6.5 days, a perilune radius of about 3,500 km, and an apolune radius of about 71,000 km; it is strongly affected by the gravity of both the Earth and the Moon simultaneously. This NRHO offers extended communications with assets on the south pole of the Moon,4 as well as low-cost orbit maintenance and attitude control,5 favorable eclipse avoidance properties,6 and inexpensive transfers from Earth and to other destinations.5,7 The NRHO portion of the southern L2 halo family is highlighted in black in Figure 1, and the 9:2 NRHO appears in blue.

Phillips, Sean M.↗
NASA NTRS2022

Lunar Communications Services with Emphasis on Commercialization

In mid-2020 Lockheed Marin Space (LM) and NASA’s Jet Propulsion Laboratory (JPL) formed a working group to study and address the need for a lunar communications network to service a growing lunar economy, beginning with the initial crewed and robotic mission needs in 2024. Multiple commercial relay architectures were studied and evaluated for platform requirements, communications capabilities, and commercial business viability in a growing ecosystem. The evolution of communications needs around the Moon were mapped to infrastructure build out. Trade studies were performed to evaluate reliability and lifetime requirements, and the viability of various data protocols. Mission concepts and operations plans were developed for both initial mission support and future autonomous network support. This work has led to Lockheed Martin and JPL to evaluate a single dedicated relay satellite in a frozen lunar orbit, with simultaneous coverage of the far-side and south pole landing sites for over 10 hours per day as a first step towards a comprehensive solution to lunar connectivity. This first satellite is compatible with an ESPA Grande launch volume and would be capable of launching on a rideshare into a variety of orbits and trajectories. The satellite is equipped with both high- and low-rate communications relay payloads with software-defined radios and a delay/disruption tolerant networking protocol. The system is designed to service initial and future mission needs in a commercialized manner, enabling a new class of missions to the Moon. The relay satellite leverages prior spacecraft platform work with on-orbit heritage in a lunar environment expected by 2023.

Davarian, Faramaz↗
NASA NTRS2002

Reusable Autonomy

Currently, spacecraft ground systems have a well defined and somewhat standard architecture and operations concept. Based on domain analysis studies of various control centers conducted over the years it is clear that ground systems have core capabilities and functionality that are common across all ground systems. This observation alone supports the realization of reuse. Additionally, spacecraft ground systems are increasing in their ability to do things autonomously. They are being engineered using advanced expert systems technology to provide automated support for operators. A clearer understanding of the possible roles of agent technology is advancing the prospects of greater autonomy for these systems. Many of their functional and management tasks are or could be supported by applied agent technology, the dynamics of the ground system's infrastructure could be monitored by agents, there are intelligent agent-based approaches to user-interfaces, etc. The premise of this paper is that the concepts associated with software reuse, applicable in consideration of classically-engineered ground systems, can be updated to address their application in highly agent-based realizations of future ground systems. As a somewhat simplified example consider the following situation, involving human agents in a ground system context. Let Group A of controllers be working on Mission X. They are responsible for the command, control and health and safety of the Mission X spacecraft. Let us suppose that mission X successfully completes it mission and is turned off. Group A could be dispersed or perhaps move to another Mission Y. In this case there would be reuse of the human agents from Mission X to Mission Y. The Group A agents perform their well-understood functions in a somewhat but related context. There will be a learning or familiarization process that the group A agents go through to make the new context, determined by the new Mission Y, understood. This simplified scenario highlights some of the major issues that need to be addressed when considering the situation where Group A is composed of software-based agents (not their human counterparts) and they migrate from one mission support system to another. This paper will address: - definition of an agent architecture appropriate to support reuse; - identification of non-mission-specific agent capabilities required; - appropriate knowledge representation schemes for mission-specific knowledge; - agent interface with mission-specific knowledge (a type of Learning); development of a fully-operational group of cooperative software agents for ground system support; architecture and operation of a repository of reusable agents that could be the source of intelligent components for realizing an autonomous (or nearly autonomous) agent-based ground system, and an agent-based approach to repository management and operation (an intelligent interface for human use of the repository in a ground-system development activity).

Truszkowski, Walt↗
NASA NTRS2004

Adaptive Bio-Inspired Wireless Network Routing for Planetary Surface Exploration

Wireless mobile networks suffer connectivity loss when used in a terrain that has hills, and valleys when line of sight is interrupted or range is exceeded. To resolve this problem and achieve acceptable network performance, we have designed an adaptive, configurable, hybrid system to automatically route network packets along the best path between multiple geographically dispersed modules. This is very useful in planetary surface exploration, especially for ad-hoc mobile networks, where computational devices take an active part in creating a network infrastructure, and can actually be used to route data dynamically and even store data for later transmission between networks. Using inspiration from biological systems, this research proposes to use ant trail algorithms with multi-layered information maps (topographic maps, RF coverage maps) to determine the best route through ad-hoc network at real time. The determination of best route is a complex one, and requires research into the appropriate metrics, best method to identify the best path, optimizing traffic capacity, network performance, reliability, processing capabilities and cost. Real ants are capable of finding the shortest path from their nest to a food source without visual sensing through the use of pheromones. They are also able to adapt to changes in the environment using subtle clues. To use ant trail algorithms, we need to define the probability function. The artificial ant is, in this case, a software agent that moves from node to node on a network graph. The function to calculate the fitness (evaluate the better path) includes: length of the network edge, the coverage index, topology graph index, and pheromone trail left behind by other ant agents. Each agent modifies the environment in two different ways: 1) Local trail updating: As the ant moves between nodes it updates the amount of pheromone on the edge; and 2) Global trail updating: When all ants have completed a tour the ant that found the shortest route updates the edges in its path.

Alena, Richard I.↗
NASA NTRS2009

Integrated System Health Management: Foundational Concepts, Approach, and Implementation

A sound basis to guide the community in the conception and implementation of ISHM (Integrated System Health Management) capability in operational systems was provided. The concept of "ISHM Model of a System" and a related architecture defined as a unique Data, Information, and Knowledge (DIaK) architecture were described. The ISHM architecture is independent of the typical system architecture, which is based on grouping physical elements that are assembled to make up a subsystem, and subsystems combine to form systems, etc. It was emphasized that ISHM capability needs to be implemented first at a low functional capability level (FCL), or limited ability to detect anomalies, diagnose, determine consequences, etc. As algorithms and tools to augment or improve the FCL are identified, they should be incorporated into the system. This means that the architecture, DIaK management, and software, must be modular and standards-based, in order to enable systematic augmentation of FCL (no ad-hoc modifications). A set of technologies (and tools) needed to implement ISHM were described. One essential tool is a software environment to create the ISHM Model. The software environment encapsulates DIaK, and an infrastructure to focus DIaK on determining health (detect anomalies, determine causes, determine effects, and provide integrated awareness of the system to the operator). The environment includes gateways to communicate in accordance to standards, specially the IEEE 1451.1 Standard for Smart Sensors and Actuators.

Figueroa, Fernando↗
NASA NTRS2012

Low-Cost Telemetry System for Small/Micro Satellites

A Software Defined Radio (SDR) concept uses a minimum amount of analog/radio frequency components to up/downconvert the RF signal to/from a digital format. Once in the digital domain, all other processing (filtering, modulation, demodulation, etc.) is done in software. The project will leverage existing designs and enhance capabilities in the commercial sector to provide a path to a radiation-hardened SDR transponder. The SDR transponder would incorporate baseline technologies dealing with improved Forward Error Correcting (FEC) codes to be deployed to all Near Earth Network (NEN) ground stations. By incorporating this FEC, at least a tenfold increase in data throughput can be achieved. A family of transponder products can be implemented using common platform architecture, allowing new products to be more quickly introduced into the market. Software can be reused across products, reducing software/hardware costs dramatically. New features and capabilities, such as encoding and decoding algorithms, filters, and bit synchronizers, can be added to the existing infrastructure without requiring major new capital expenditures, allowing implementation of advanced features in the communication systems. As new telecommunication technologies emerge, incorporating them into the SDR fabric will be easily accomplished with little or no requirements for new hardware. There are no preferred flight platforms for the SDR technology, so it can be used on any type of orbital or sub-orbital platform, all within a fully radiation hardened design.

Sims, William↗
NASA NTRS2016

Future Standardization of Space Telecommunications Radio System with Core Flight System

NASA Glenn Research Center (GRC) is integrating the NASA Space Telecommunications Radio System (STRS) Standard with the Core Flight System (cFS). The STRS standard provides a common, consistent framework to develop, qualify, operate and maintain complex, reconfigurable and reprogrammable radio systems. The cFS is a flexible, open architecture that features a plug-and-play software executive called the Core Flight Executive (cFE), a reusable library of software components for flight and space missions and an integrated tool suite. Together, STRS and cFS create a development environment that allows for STRS compliant applications to reference the STRS APIs through the cFS infrastructure. These APis are used to standardize the communication protocols on NASAs space SDRs. The cFE-STRS Operating Environment (OE) is a portable cFS library, which adds the ability to run STRS applications on existing cFS platforms. The purpose of this paper is to discuss the cFE-STRS OE prototype, preliminary experimental results performed using the Advanced Space Radio Platform (ASRP), the GRC Sband Ground Station and the SCaN (Space Communication and Navigation) Testbed currently flying onboard the International Space Station. Additionally, this paper presents a demonstration of the Consultative Committee for Space Data Systems (CCSDS) Spacecraft Onboard Interface Services (SOIS) using electronic data sheets inside cFE. This configuration allows for the data sheets to specify binary formats for data exchange between STRS applications. The integration of STRS with cFS leverages mission-proven platform functions and mitigates barriers to integration with future missions. This reduces flight software development time and the costs of software-defined radio (SDR) platforms. Furthermore, the combined benefits of STRS standardization with the flexibility of cFS provide an effective, reliable and modular framework to minimize software development efforts for spaceflight missions.

space communications↗
NASA NTRS2016

Future Standardization of Space Telecommunications Radio System with Core Flight System

NASA Glenn Research Center (GRC) is integrating the NASA Space Telecommunications Radio System (STRS) Standard with the Core Flight System (cFS), an avionics software operating environment. The STRS standard provides a common, consistent framework to develop, qualify, operate and maintain complex, reconfigurable and reprogrammable radio systems. The cFS is a flexible, open architecture that features a plugand- play software executive called the Core Flight Executive (cFE), a reusable library of software components for flight and space missions and an integrated tool suite. Together, STRS and cFS create a development environment that allows for STRS compliant applications to reference the STRS application programmer interfaces (APIs) that use the cFS infrastructure. These APIs are used to standardize the communication protocols on NASAs space SDRs. The cFS-STRS Operating Environment (OE) is a portable cFS library, which adds the ability to run STRS applications on existing cFS platforms. The purpose of this paper is to discuss the cFS-STRS OE prototype, preliminary experimental results performed using the Advanced Space Radio Platform (ASRP), the GRC S‑ band Ground Station and the SCaN (Space Communication and Navigation) Testbed currently flying onboard the International Space Station (ISS). Additionally, this paper presents a demonstration of the Consultative Committee for Space Data Systems (CCSDS) Spacecraft Onboard Interface Services (SOIS) using electronic data sheets (EDS) inside cFE. This configuration allows for the data sheets to specify binary formats for data exchange between STRS applications. The integration of STRS with cFS leverages mission-proven platform functions and mitigates barriers to integration with future missions. This reduces flight software development time and the costs of software-defined radio (SDR) platforms. Furthermore, the combined benefits of STRS standardization with the flexibility of cFS provide an effective, reliable and modular framework to minimize software development efforts for spaceflight missions.

space communications↗
NASA NTRS2005

Evaluation of a Shuttle Derived Vehicle (SDV) for Cargo Transportation

In this new era of space exploration, a host of launch vehicles are being examined for possible use in transporting cargo and crew to low Earth orbit and beyond. Launch vehicles derived from the Space Shuttle Program (SSP), known as Shuttle Derived Vehicles (SDVs), are prime candidates for heavy-lift duty because of their potential to minimize non-recurring costs and because the Shuttle can leverage off proven high-performance flight systems with established ground and flight support. To determine the merits of SDVs, a detailed evaluation was performed. This evaluation included a trade study and risk assessment of options based on performance, safety reliability, cost, operations, and evolution. The purpose of this paper is to explain the approach, processes, and tools used to evaluate launch vehicles for heavy lift cargo transportation. The process included defining the trade space, characterizing the concepts, analyzing the systems, and scoring the options. The process also included a review by subject experts from NASA and industry to compare past and recent study data and assess the risks. A set of technical performance measures (TPMs) was generated based on the study requirements and constraints. Tools such as INTROS and POST were used to calculate performance, FIRST was used for prediction of reliability, and other software packages, both commercial and NASA-owned, were applied to study the trade space. By following a clear process and using the right tools a thorough assessment was performed. An SDV can be classified as either a side-mount vehicle (SMV) or an in-line vehicle OLV). An SMV is a Space Shuttle where the Orbiter is replaced by a cargo carrier. An ILV is comprised of a modified Shuttle External Tank (ET) with engines mounted to the bottom and cargo mounted atop. For both families of vehicles, Solid Rocket Boosters (SRBs) are attached to the ET. The first derivate of Shuttle is defined as the vehicle with minimum changes necessary to transform the Space Shuttle into an SDV. Deltas from the first derivate were also formulated to study more SDV options. Examples of deltas include replacing the SRBs with larger and/or more SRBs, adding an upper stage, increasing the size of the ET, changing the engines, and modifying the elements. Challenges for SDV range from tailoring infrastructure to meeting the exploration schedule. Although SDV is based on the Space Shuttle, it still includes development risk for designing and building a Cargo Carrier. There are also performance challenges in that Shuttle is not optimized for cargo-only missions, but it is a robust system built on reusability. Balancing the strengths and weaknesses of the Shuttle to meet Lunar and Mars mission objectives provides the framework for an informative trade study. SDV was carefully analyzed and the results of the study provide invaluable data for use in the new exploration initiative.

Roman, Jose M.↗
NASA NTRS2021

Lunar Asset Messaging and On Orbit Navigation

NASA has titled its 2020 thrust for the Moon, Artemis. The increased focus on the Moon as a destination for future human and robotic expeditions necessitates general purpose navigational and communications infrastructure reducing their complexity to help establish a sustained presence. A framework through which Lunar missions can relay communications and localize their positions shifts the burden from the individual mission and enables resource allocation tailored to mission-specific goals. During the summer of 2020, student interns under the Innovation to Flight (i2F) program at the National Aeronautics and Space Administration’s (NASA) Jet Propulsion Laboratory (JPL) in collaboration with the University of Colorado Boulder designed, built, and tested a prototype framework capable of providing surface assets with communication and positioning services. The team utilized the existing i2F CubeSat bus in addition to developing several CubeSat engineering development units (EDUs), a ground vehicle, and a ground station to simulate a scenario in which a lunar surface mission is supported by these services. A primary goal of the summer was to develop a method for localizing the ground vehicle through trilateration. Distances are inferred from the round-trip time of flight (ToF) of radio signals between an asset and several elements. Signals were sent and received using LimeSDR software defined radios on-board both the ground vehicle and the EDUs; ToF and trilateration were calculated on a Qualcomm Snapdragon development board located within the LA MOON payload data system. The ModalAI chipset on the Qualcomm was instrumental in executing visual based position estimation. Communications was facilitated through a bent-pipe approach addressing the NASA requirement to provide solutions for in communication denied locations. The ground vehicle relayed information to other surface assets in addition to its ground station through the supporting constellation. This project demonstrates the feasibility of a lunar CubeSat constellation for the support of surface assets and explores packaging and operations of the components critical to trilateration and bent-pipe communication into a standard CubeSat form factor. When implemented, this framework will open a door for new surface missions designed with lower power requirements and increased operational access.

Huang, Calvin↗
NASA NTRS2010

Handling Emergency Management in [an] Object Oriented Modeling Environment

It has been understood that protection of a nation from extreme disasters is a challenging task. Impacts of extreme disasters on a nation's critical infrastructures, economy and society could be devastating. A protection plan itself would not be sufficient when a disaster strikes. Hence, there is a need for a holistic approach to establish more resilient infrastructures to withstand extreme disasters. A resilient infrastructure can be defined as a system or facility that is able to withstand damage, but if affected, can be readily and cost-effectively restored. The key issue to establish resilient infrastructures is to incorporate existing protection plans with comprehensive preparedness actions to respond, recover and restore as quickly as possible, and to minimize extreme disaster impacts. Although national organizations will respond to a disaster, extreme disasters need to be handled mostly by local emergency management departments. Since emergency management departments have to deal with complex systems, they have to have a manageable plan and efficient organizational structures to coordinate all these systems. A strong organizational structure is the key in responding fast before and during disasters, and recovering quickly after disasters. In this study, the entire emergency management is viewed as an enterprise and modelled through enterprise management approach. Managing an enterprise or a large complex system is a very challenging task. It is critical for an enterprise to respond to challenges in a timely manner with quick decision making. This study addresses the problem of handling emergency management at regional level in an object oriented modelling environment developed by use of TopEase software. Emergency Operation Plan of the City of Hampton, Virginia, has been incorporated into TopEase for analysis. The methodology used in this study has been supported by a case study on critical infrastructure resiliency in Hampton Roads.

Tokgoz, Berna Eren↗
NASA NTRS1995

The Experience Factory: Strategy and Practice

The quality movement, that has had in recent years a dramatic impact on all industrial sectors, has recently reached the system and software industry. Although some concepts of quality management, originally developed for other product types, can be applied to software, its specificity as a product which is developed and not produced requires a special approach. This paper introduces a quality paradigm specifically tailored on the problem of the systems and software industry. Reuse of products, processes and experiences originating from the system life cycle is seen today as a feasible solution to the problem of developing higher quality systems at a lower cost. In fact, quality improvement is very often achieved by defining and developing an appropriate set of strategic capabilities and core competencies to support them. A strategic capability is, in this context, a corporate goal defined by the business position of the organization and implemented by key business processes. Strategic capabilities are supported by core competencies, which are aggregate technologies tailored to the specific needs of the organization in performing the needed business processes. Core competencies are non-transitional, have a consistent evolution, and are typically fueled by multiple technologies. Their selection and development requires commitment, investment and leadership. The paradigm introduced in this paper for developing core competencies is the Quality Improvement Paradigm which consists of six steps: (1) Characterize the environment, (2) Set the goals, (3) Choose the process, (4) Execute the process, (5) Analyze the process data, and (6) Package experience. The process must be supported by a goal oriented approach to measurement and control, and an organizational infrastructure, called Experience Factory. The Experience Factory is a logical and physical organization distinct from the project organizations it supports. Its goal is development and support of core competencies through capitalization and reuse of its cycle experience and products. The paper introduces the major concepts of the proposed approach, discusses their relationship with other approaches used in the industry, and presents a case in which those concepts have been successfully applied.

Basili, Victor R.↗
NASA NTRS2008

Evolution and Reengineering of NASA's Flight Dynamics Facility (FDF)

The NASA Goddard Space Flight Center's Flight Dynamics Facility (FDF) is a multimission support facility that performs ground navigation and spacecraft trajectory design services for a wide range of scientific satellites. The FDF also supports the NASA Space Network by providing orbit determination and tracking data evaluation services for the Tracking Data Relay Satellite System (TDRSS). The FDF traces its history to early NASA missions in the 1960's, including navigation support to the Apollo lunar missions. Over its 40 year history, the FDF has undergone many changes in its architecture, services offered, missions supported, management approach, and business operation. As a fully reimbursable facility (users now pay 100% of all costs for FDF operations and sustaining engineering activities), the FDF has faced significant challenges in recent years in providing mission critical products and services at minimal cost while defining and implementing upgrades necessary to meet future mission demands. This paper traces the history of the FDF and discusses significant events in the past that impacted the FDF infrastructure and/or business model, and the events today that are shaping the plans for the FDF in the next decade. Today's drivers for change include new mission requirements, the availability of new technology for spacecraft navigation, and continued pressures for cost reduction from FDF users. Recently, the FDF completed an architecture study based on these drivers that defines significant changes planned for the facility. This paper discusses the results of this study and a proposed implementation plan. As a case study in how flight dynamics operations have evolved and will continue to evolve, this paper focuses on two periods of time (1992 and the present) in order to contrast the dramatic changes that have taken place in the FDF. This paper offers observations and plans for the evolution of the FDF over the next ten years. Finally, this paper defines the mission model of the future for the FDF based on NASA's current mission list and planning for the Constellation Program. As part of this discussion the following are addressed: the relevance and benefits of a multi-mission facility for NASA's navigation operations in the future; anticipated technologies affecting ground orbit determination; continued incorporation of Commercial Off-the-shelf (COTS) software into the FDF; challenges of a business model that relies entirely on user fees to fund facility upgrades; anticipated changes in flight dynamics services required; and considerations for defining architecture upgrades given a set of cost drivers.

Stengle, Thomas↗
NASA NTRS2021

PEM Fuel Cell MODEL for Conceptual Design of Hydrogen eVTOL Aircraft

A model and software for design and analysis of a Proton Exchange Membrane fuel cell (PEMFC) system are developed for hydrogen eVTOL aircraft. Examples are provided of stacks designed for 80 kWe and 500 kWe net electrical power. Examples are provided of eVTOL designed for 250 and 400 lb payload. The trade-offs included stack characteristics, hydrogen storage characteristics, and aircraft payload and range. The objectives were to identify the key technology drivers of a hydrogen rotorcraft, establish technology targets for a viable aircraft, and recommend research to address the fundamental pre-competitive barriers. The current U.S. infrastructure on hydrogen informed the targets and recommendations. The key conclusion is that the advances made in cell electrochemical power density over the last decade might allow a PEMFC system to meet, or even beat, piston engine powered light-utility rotorcraft. The development must focus on the key drivers of a hydrogen eVTOL. The drivers are ultra-light stack cooling and short-term hydrogen storage. A stack system of net electrical power 100−150 kWe with specific power 1.1 kWe/kg including air, cooling, and electrical subsystems, and a tank storage of 15% weight fraction hydrogen are the minimum targets to meet the performance of a modern piston-engine rotorcraft, with a range of 180 nautical miles, payload of 400 lb, and gross weight of about 1400 lb. This is defined as the objective aircraft. If only one target is met, an aircraft of half the range could be produced, with a 30% greater gross take-off weight. This is defined as an intermediate aircraft. Because definitive conclusions are premature without weights and loads data on a flight-worthy stack system, it is recommended that a fuel cell powered hydrogen eVTOL demonstrator be built and flown. The existing hydrogen infrastructure for cars provide ample opportunity to create a pilot program. About 12 metric tons of retail hydrogen are available for cars every day in California, which is less than 0.05% of the yearly hydrogen production in the U.S.. A hypothetical fleet of 100 aircraft, operating 3 flights a day, would increase the demand by 2.25 tons per day and require 140 MWh of renewable electricity for green hydrogen.

PEM↗
NASA NTRS1994

SCOS 2: An object oriented software development approach

The Spacecraft Control and Operations System 2 (SCOS 2), is intended to provide the generic mission control system infrastructure for future ESA missions. It represents a bold step forward in order to take advantage of state-of-the-art technology and current practices in the area of software engineering. Key features include: (1) use of object oriented analysis and design techniques; (2) use of UNIX, C++ and a distributed architecture as the enabling implementation technology; (3) goal of re-use for development, maintenance and mission specific software implementation; and (4) introduction of the concept of a spacecraft control model. This paper touches upon some of the traditional beliefs surrounding Object Oriented development and describes their relevance to SCOS 2. It gives rationale for why particular approaches were adopted and others not, and describes the impact of these decisions. The development approach followed is discussed, highlighting the evolutionary nature of the overall process and the iterative nature of the various tasks carried out. The emphasis of this paper is on the process of the development with the following being covered: (1) the three phases of the SCOS 2 project - prototyping & analysis, design & implementation and configuration / delivery of mission specific systems; (2) the close cooperation and continual interaction with the users during the development; (3) the management approach - the split between client staff, industry and some of the required project management activities; (4) the lifecycle adopted being an enhancement of the ESA PSS-05 standard with SCOS 2 specific activities and approaches defined; and (5) an examination of some of the difficulties encountered and the solutions adopted. Finally, the lessons learned from the SCOS 2 experience are highlighted, identifying those issues to be used as feedback into future developments of this nature. This paper does not intend to describe the finished product and its operation, but focusing on the journey to arrive there, concentrating therefore on the process and not the products of the SCOS 2 software development.

Symonds, Martin↗