SEARCH · Engineering Papers

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.

SourceResearch connectionFrom yearThrough year

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

At least 199 records · Page 11

All sources NASA NTRS DOE OSTI

NASA NTRS2012

Engineering a Multimission Approach to Navigation Ground Data System Operations

The Mission Design and Navigation (MDNAV) Section at the Jet Propulsion Laboratory (JPL) supports many deep space and earth orbiting missions from formulation to end of mission operations. The requirements of these missions are met with a multimission approach to MDNAV ground data system (GDS) infrastructure capable of being shared and allocated in a seamless and consistent manner across missions. The MDNAV computing infrastructure consists of compute clusters, network attached storage, mission support area facilities, and desktop hardware. The multimission architecture allows these assets, and even personnel, to be leveraged effectively across the project lifecycle and across multiple missions simultaneously. It provides a more robust and capable infrastructure to each mission than might be possible if each constructed its own. It also enables a consistent interface and environment within which teams can conduct all mission analysis and navigation functions including: trajectory design; ephemeris generation; orbit determination; maneuver design; and entry, descent, and landing analysis. The savings of these efficiencies more than offset the costs of increased complexity and other challenges that had to be addressed: configuration management, scheduling conflicts, and competition for resources. This paper examines the benefits of the multimission MDNAV ground data system infrastructure, focusing on the hardware and software architecture. The result is an efficient, robust, scalable MDNAV ground data system capable of supporting more than a dozen active missions at once.

Mission Design and Navigation (MDNAV)↗

DOE OSTI2022

Reekeekee- and roodoodooviruses, two different Microviridae clades constituted by the smallest DNA phages

Small circular single-stranded DNA viruses of the Microviridae family are both prevalent and diverse in all ecosystems. They usually harbor a genome between 4.3 and 6.3 kb, with a microvirus recently isolated from a marine Alphaproteobacteria being the smallest known genome of a DNA phage (4.248 kb). A subfamily, Amoyvirinae, has been proposed to classify this virus and other related small Alphaproteobacteria-infecting phages. Here, we report the discovery, in meta-omics data sets from various aquatic ecosystems, of sixteen complete microvirus genomes significantly smaller (2.991–3.692 kb) than known ones. Phylogenetic analysis reveals that these sixteen genomes represent two related, yet distinct and diverse, novel groups of microviruses—amoyviruses being their closest known relatives. We propose that these small microviruses are members of two tentatively named subfamilies Reekeekeevirinae and Roodoodoovirinae. As known microvirus genomes encode many overlapping and overprinted genes that are not identified by gene prediction software, we developed a new methodology to identify all genes based on protein conservation, amino acid composition, and selection pressure estimations. Surprisingly, only four to five genes could be identified per genome, with the number of overprinted genes lower than that in phiX174. These small genomes thus tend to have both a lower number of genes and a shorter length for each gene, leaving no place for variable gene regions that could harbor overprinted genes. Even more surprisingly, these two Microviridae groups had specific and different gene content, and major differences in their conserved protein sequences, highlighting that these two related groups of small genome microviruses use very different strategies to fulfill their lifecycle with such a small number of genes. The discovery of these genomes and the detailed prediction and annotation of their genome content expand our understanding of ssDNA phages in nature and are further evidence that these viruses have explored a wide range of possibilities during their long evolution.

59 BASIC BIOLOGICAL SCIENCES↗

NASA NTRS2006

Integrated Vehicle Health Management (IVHM) for Aerospace Systems

To achieve NASA's ambitious Integrated Space Transportation Program objectives, aerospace systems will implement a variety of new concept in health management. System level integration of IVHM technologies for real-time control and system maintenance will have significant impact on system safety and lifecycle costs. IVHM technologies will enhance the safety and success of complex missions despite component failures, degraded performance, operator errors, and environment uncertainty. IVHM also has the potential to reduce, or even eliminate many of the costly inspections and operations activities required by current and future aerospace systems. This presentation will describe the array of NASA programs participating in the development of IVHM technologies for NASA missions. Future vehicle systems will use models of the system, its environment, and other intelligent agents with which they may interact. IVHM will be incorporated into future mission planners, reasoning engines, and adaptive control systems that can recommend or execute commands enabling the system to respond intelligently in real time. In the past, software errors and/or faulty sensors have been identified as significant contributors to mission failures. This presentation will also address the development and utilization of highly dependable sohare and sensor technologies, which are key components to ensure the reliability of IVHM systems.

Baroth, Edmund C.↗

NASA NTRS2008

Enabling and Enhancing Space Mission Success and Reduction of Risk through the Application of an Integrated Data Architecture

The engineering phases of design, development, test, and evaluation (DDT and E) and subsequent planning, preparation, and operation (Ops) of space vehicles in a complex and distributed environment requires massive and continuous flows of information across the enterprise and across temporal stages of the vehicle lifecycle. The resulting capabilities at each subsequent stage depend in part on the capture, preparation, storage, and subsequent provision of information from prior stages. The United States National Aeronautics and Space Administration (NASA) is currently designing a fleet of new vehicles that will replace the Space Shuttle and expand space operations and exploration capabilities. This includes the 2 stage human rated lift vehicle Ares 1 and its associated crew vehicle the Orion, and a service module; the heavy lift cargo vehicle, Ares 5, and an associated cargo stage known as the Earth Departure Stage; and a Lunar Lander vehicle that contains a descent stage, and ascent stage, and a habitation module. A variety of concurrent assorted ground operations infrastructure including software and facilities are also being developed, assorted technology and assembly designs and development for equipment such as EVA suits, life support systems, command and control technologies are also in the pipeline. The development is occurring in a distributed manner, with project deliverables being contributed by a large and diverse assortment of vendors and most space faring nations. Critical information about all of the components, software, and procedures must be shared during the DDT and E phases and then made readily available to the mission operations staff for access during the planning, preparation, and operations phases, and also need to be readily available for system to system interactions. The Constellation Data Systems Project (CxDS) is identifying the needs, and designing and deploying systems and processes to support these needs. This paper details the steps and processes that NASA is applying within the Constellation Program to manage this data and information, and to insure that the correct information is available, correctly annotated, and can be provisioned digitally to enhance response times, and support engineering analysis and anomaly resolution.

Brummett, Robert C.↗

NASA NTRS2013

Practical Application of PRA as an Integrated Design Tool for Space Systems

This paper presents the application of the first comprehensive Probabilistic Risk Assessment (PRA) during the design phase of a joint NASA/NOAA weather satellite program, Geostationary Operational Environmental Satellite Series R (GOES-R). GOES-R is the next generation weather satellite primarily to help understand the weather and help save human lives. PRA has been used at NASA for Human Space Flight for many years. PRA was initially adopted and implemented in the operational phase of manned space flight programs and more recently for the next generation human space systems. Since its first use at NASA, PRA has become recognized throughout the Agency as a method of assessing complex mission risks as part of an overall approach to assuring safety and mission success throughout project lifecycles. PRA is now included as a requirement during the design phase of both NASA next generation manned space vehicles as well as for high priority robotic missions. The influence of PRA on GOES-R design and operation concepts are discussed in detail. The GOES-R PRA is unique at NASA for its early implementation. It also represents a pioneering effort to integrate risks from both Spacecraft (SC) and Ground Segment (GS) to fully assess the probability of achieving mission objectives. PRA analysts were actively involved in system engineering and design engineering to ensure that a comprehensive set of technical risks were correctly identified and properly understood from a design and operations perspective. The analysis included an assessment of SC hardware and software, SC fault management system, GS hardware and software, common cause failures, human error, natural hazards, solar weather and infrastructure (such as network and telecommunications failures, fire). PRA findings directly resulted in design changes to reduce SC risk from micro-meteoroids. PRA results also led to design changes in several SC subsystems, e.g. propulsion, guidance, navigation and control (GNC), communications, mechanisms, and command and data handling (C&DH). The fault tree approach assisted in the development of the fault management system design. Human error analysis, which examined human response to failure, indicated areas where automation could reduce the overall probability of gaps in operation by half. In addition, the PRA brought to light many potential root causes of system disruptions, including earthquakes, inclement weather, solar storms, blackouts and other extreme conditions not considered in the typical reliability and availability analyses. Ultimately the PRA served to identify potential failures that, when mitigated, resulted in a more robust design, as well as to influence the program's concept of operations. The early and active integration of PRA with system and design engineering provided a well-managed approach for risk assessment that increased reliability and availability, optimized lifecyc1e costs, and unified the SC and GS developments.

Kalia, Prince↗

NASA NTRS2006

Mission Scenario Development Workbench

The Mission Scenario Development Workbench (MSDW) is a multidisciplinary performance analysis software tool for planning and optimizing space missions. It provides a number of new capabilities that are particularly useful for planning the surface activities on other planets. MSDW enables rapid planning of a space mission and supports flight system and scientific-instrumentation trades. It also provides an estimate of the ability of flight, ground, and science systems to meet high-level mission goals and provides means of evaluating expected mission performance at an early stage of planning in the project life cycle. In MSDW, activity plans and equipment-list spreadsheets are integrated with validated parameterized simulation models of spacecraft systems. In contrast to traditional approaches involving worst-case estimates with large margins, the approach embodied in MSDW affords more flexibility and more credible results early in the lifecycle through the use of validated, variable- fidelity models of spacecraft systems. MSDW is expected to help maximize the scientific return on investment for space missions by understanding early the performance required to have a successful mission while reducing the risk of costly design changes made at late stages in the project life cycle.

Kordon, Mark↗

NASA NTRSDate not supplied

Trustworthy Autonomy for Gateway Vehicle System Manager

The Vehicle System Manager (VSM) is the highest-level software control system in the Gateway hierarchical Autonomous System Management Architecture. The VSM provides four function categories: Mission Management and Timeline Execution, Resource Management, Fault Management, Vehicle Control and Operation. VSM provides various levels of automation ranging from fully autonomous operations with no flight crew and minimal ground monitoring to advisory automation when Gateway is crewed and has full ground monitoring. Trustworthiness is achieved via verified specification, comprehensive development verification, and real-time verification using assume-guarantee contracts. Development verification includes semantic verification of the data model via peer review and testing and assume-guarantee contracts implemented using the PlusCal/TLA+ environment. VSM also uses runtime assume-guarantee contracts, implemented in R2U2 via a runtime monitor that feeds the necessary telemetry data to R2U2 and which receives and responds to the R2U2 verdict stream. The full lifecycle verification approach and use of assume-guarantee contracts provides increased trustworthiness to VSM. Preliminary results provide encouragement that VSM can be both autonomous and trustworthy.

Assume-guarantee contracts↗

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↗

DOE OSTI2014

A Report on Simulation-Driven Reliability and Failure Analysis of Large-Scale Storage Systems

High-performance computing (HPC) storage systems provide data availability and reliability using various hardware and software fault tolerance techniques. Usually, reliability and availability are calculated at the subsystem or component level using limited metrics such as, mean time to failure (MTTF) or mean time to data loss (MTTDL). This often means settling on simple and disconnected failure models (such as exponential failure rate) to achieve tractable and close-formed solutions. However, such models have been shown to be insufficient in assessing end-to-end storage system reliability and availability. We propose a generic simulation framework aimed at analyzing the reliability and availability of storage systems at scale, and investigating what-if scenarios. The framework is designed for an end-to-end storage system, accommodating the various components and subsystems, their interconnections, failure patterns and propagation, and performs dependency analysis to capture a wide-range of failure cases. We evaluate the framework against a large-scale storage system that is in production and analyze its failure projections toward and beyond the end of lifecycle. We also examine the potential operational impact by studying how different types of components affect the overall system reliability and availability, and present the preliminary results

97 MATHEMATICS AND COMPUTING↗

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↗