Search NASA⌕ Search

SEARCH · Search NASA

Results for “lessons learned information system process improvement”

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 NTRSDate not supplied

Conclusions of a Mini Technical Interchange Meeting on Mechanisms and Pathways Common Between Adverse Health Outcomes from Exposures to Space Radiation

To enable deep space exploration and sustained human presence in space, the NASA Human Research Program’s (HRP) Space Radiation Element (SRE) funds research to characterize and mitigate adverse health outcomes from exposure to space radiation that include risks of carcinogenesis, cardiovascular disease (CVD) and central nervous system (CNS) decrements. Over the past decade, a growing body of compelling experimental evidence suggests shared mechanisms and pathophysiological processes for CVD, neurodegenerative effects, and cancer development and progression, which are traditionally managed as separate disease processes. Additionally, epidemiological studies have identified cross-sectional and longitudinal associations between some specific types of cancer and CVD, and accumulating evidence indicates that the pathogenesis of neurodegenerative diseases such as Alzheimer’s disease may overlap with CVD and cancer pathogenesis. Identifying the mechanisms and pathways common to these important health decrements will not only accelerate development of effective countermeasures and improve management of spaceflight-induced risk, it will also help to develop new treatment strategies for patients on Earth. To identify common pathways and mechanisms of disease induction and progression from current SR-funded studies and to inform future work and solicitations, the SRE organizes themed sessions at annual HRP Investigators’ Workshops (IWS). These technical interchange meetings (TIMs) provide a venue for the scientific community to present ongoing work and engage in open discussion on results, limitations of current approaches, and incorporation of novel experimental strategies, model systems, and other innovative techniques. Here a summary and lessons learned from the SRE-sponsored mini-TIM titled “mechanisms and pathways common between adverse health outcomes” held at HRP IWS 2023 will be communicated. The 90-min TIM had 30-min dedicated to discussing and developing potential collaboration and tissue sharing opportunities among investigators. The SRE facilitated the discussion using a set of pressing questions and gaps in knowledge that need to be addressed by the scientific community. This poster presents the outcomes of the session along with proposed future workshops and other SRE initiatives.

Janapriya Saha↗
NASA NTRSDate not supplied

Conclusions of a Mini Technical Interchange Meeting on Mechanisms and Pathways Common Between Adverse Health Outcomes from Exposures to Space Radiation

To enable deep space exploration and sustained human presence in space, the NASA Human Research Program’s (HRP) Space Radiation Element (SRE) funds research to characterize and mitigate adverse health outcomes from exposure to space radiation that include risks of carcinogenesis, cardiovascular disease (CVD) and central nervous system (CNS) decrements. Over the past decade, a growing body of compelling experimental evidence suggests shared mechanisms and pathophysiological processes for CVD, neurodegenerative effects, and cancer development and progression, which are traditionally managed as separate disease processes. Additionally, epidemiological studies have identified cross-sectional and longitudinal associations between some specific types of cancer and CVD, and accumulating evidence indicates that the pathogenesis of neurodegenerative diseases such as Alzheimer’s disease may overlap with CVD and cancer pathogenesis. Identifying the mechanisms and pathways common to these important health decrements will not only accelerate development of effective countermeasures and improve management of spaceflight-induced risk, it will also help to develop new treatment strategies for patients on Earth. To identify common pathways and mechanisms of disease induction and progression from current SR-funded studies and to inform future work and solicitations, the SRE organizes themed sessions at annual HRP Investigators’ Workshops (IWS). These technical interchange meetings (TIMs) provide a venue for the scientific community to present ongoing work and engage in open discussion on results, limitations of current approaches, and incorporation of novel experimental strategies, model systems, and other innovative techniques. Here a summary and lessons learned from the SRE-sponsored mini-TIM titled “mechanisms and pathways common between adverse health outcomes” held at HRP IWS 2023 will be communicated. The 90-min TIM had 30-min dedicated to discussing and developing potential collaboration and tissue sharing opportunities among investigators. The SRE facilitated the discussion using a set of pressing questions and gaps in knowledge that need to be addressed by the scientific community. This poster presents the outcomes of the session along with proposed future workshops and other SRE initiatives.

Janapriya Saha↗
NASA NTRS2012

Principles to Products: Toward Realizing MOS 2.0

This is a report on the Operations Revitalization Initiative, part of the ongoing NASA-funded Advanced Multi-Mission Operations Systems (AMMOS) program. We are implementing products that significantly improve efficiency and effectiveness of Mission Operations Systems (MOS) for deep-space missions. We take a multi-mission approach, in keeping with our organization's charter to "provide multi-mission tools and services that enable mission customers to operate at a lower total cost to NASA." Focusing first on architectural fundamentals of the MOS, we review the effort's progress. In particular, we note the use of stakeholder interactions and consideration of past lessons learned to motivate a set of Principles that guide the evolution of the AMMOS. Thus guided, we have created essential patterns and connections (detailed in companion papers) that are explicitly modeled and support elaboration at multiple levels of detail (system, sub-system, element...) throughout a MOS. This architecture is realized in design and implementation products that provide lifecycle support to a Mission at the system and subsystem level. The products include adaptable multi-mission engineering documentation that describes essentials such as operational concepts and scenarios, requirements, interfaces and agreements, information models, and mission operations processes. Because we have adopted a model-based system engineering method, these documents and their contents are meaningfully related to one another and to the system model. This means they are both more rigorous and reusable (from mission to mission) than standard system engineering products. The use of models also enables detailed, early (e.g., formulation phase) insight into the impact of changes (e.g., to interfaces or to software) that is rigorous and complete, allowing better decisions on cost or technical trades. Finally, our work provides clear and rigorous specification of operations needs to software developers, further enabling significant gains in productivity.

AMMOS↗
NASA NTRS2019

The Value of Being a Trustworthy Repository

Today, NASA's Earth Observing System Data and Information System (EOSDIS), a system ofactive archives is attaching the CoreTrustSeal to its websites signifying that it merits theconfidence of its user community. But what value does being a trustworthy repository impart to auser? What does it mean to the owners and operators of repositories? What will it mean in thefuture? EOSDIS was started in the 1990s based on a framework of discipline-oriented, geographicallydistributed centers of expertise, named Distributed Active Archive Centers (DAACs). The functionof EOSDIS is to collect Earth Science data sensor measurements (principally those created andneeded by NASA) and manage the data and many derived digital products. EOSDIS providesmany services, including processing, curating, documenting, disseminating, and enabling datadiscovery as well as efficient use of the data. The EOSDIS has been operational over 25 years andmany lessons have been learned relative to the TRUST principles. During the tenure of EOSDIS,many changes have occurred as we have increased the size of the collection from gigabytes totens of petabytes and the distribution of the data to millions of users. We have had severalstages of system evolution that have improved EOSDIS in order to meet both stakeholder andcustomer expectations. This type of evolution is an on-going process to ensure that ourrepositories remain trustworthy. It is also important that our own community of data managersand system engineers add value in being trustworthy. This paper will discuss approaches to change within a large system of Earth Science data and services, while remaining a trustworthyrepository.

Behnke, Jeanne↗
NASA NTRS1999

Aerospace Engineering Systems

Continuous improvement of aerospace product development processes is a driving requirement across much of the aerospace community. As up to 90% of the cost of an aerospace product is committed during the first 10% of the development cycle, there is a strong emphasis on capturing, creating, and communicating better information (both requirements and performance) early in the product development process. The community has responded by pursuing the development of computer-based systems designed to enhance the decision-making capabilities of product development individuals and teams. Recently, the historical foci on sharing the geometrical representation and on configuration management are being augmented: Physics-based analysis tools for filling the design space database; Distributed computational resources to reduce response time and cost; Web-based technologies to relieve machine-dependence; and Artificial intelligence technologies to accelerate processes and reduce process variability. Activities such as the Advanced Design Technologies Testbed (ADTT) project at NASA Ames Research Center study the strengths and weaknesses of the technologies supporting each of these trends, as well as the overall impact of the combination of these trends on a product development event. Lessons learned and recommendations for future activities will be reported.

VanDalsem, William R.↗
NASA NTRS1999

Aerospace Engineering Systems and the Advanced Design Technologies Testbed Experience

Continuous improvement of aerospace product development processes is a driving requirement across much of the aerospace community. As up to 90% of the cost of an aerospace product is committed during the first 10% of the development cycle, there is a strong emphasis on capturing, creating, and communicating better information (both requirements and performance) early in the product development process. The community has responded by pursuing the development of computer-based systems designed to enhance the decision-making capabilities of product development individuals and teams. Recently, the historical foci on sharing the geometrical representation and on configuration management are being augmented: 1) Physics-based analysis tools for filling the design space database; 2) Distributed computational resources to reduce response time and cost; 3) Web-based technologies to relieve machine-dependence; and 4) Artificial intelligence technologies to accelerate processes and reduce process variability. The Advanced Design Technologies Testbed (ADTT) activity at NASA Ames Research Center was initiated to study the strengths and weaknesses of the technologies supporting each of these trends, as well as the overall impact of the combination of these trends on a product development event. Lessons learned and recommendations for future activities are reported.

VanDalsem, William R.↗
NASA NTRS2008

NASA's Ares I and Ares V Launch Vehicles -- Effective Space Operations Through Efficient Ground Operations

The United States (U.S.) plans to return to the Moon by 2020, with the development of a new human-rated space transportation system to replace the Space Shuttle, which is due for retirement in 2010 after it completes its missions of building the International Space Station and servicing the Hubble Space Telescope. Powering the future of space-based scientific exploration will be the Ares I Crew Launch Vehicle, which will transport the Orion Crew Exploration Vehicle to orbit where it will rendezvous with the Lunar Lander. which will be delivered by the Ares V Cargo Launch Vehicle. This new transportation infrastructure, developed by the National Aeronautics and Space Administration (NASA), will allow astronauts to leave low-Earth orbit for extended lunar exploration and preparation for the first footprint on Mars. All space-based operations begin and are controlled from Earth. NASA's philosophy is to deliver safe, reliable, and cost-effective solutions to sustain a multi-billion-dollar program across several decades. Leveraging 50 years of lessons learned, NASA is partnering with private industry, while building on proven hardware experience. This paper will discuss how the Engineering Directorate at NASA's Marshall Space Flight Center is working with the Ares Projects Office to streamline ground operations concepts and reduce costs. Currently, NASA's budget is around $17 billion, which is less than 1 percent of the U.S. Federal budget. Of this amount, NASA invests approximately $4.5 billion each year in Space Shuttle operations, regardless of whether the spacecraft is flying or not. The affordability requirement is for the Ares I to reduce this expense by 50 percent, in order to allow NASA to invest more in space-based scientific operations. Focusing on this metric, the Engineering Directorate provides several solutions-oriented approaches, including Lean/Six Sigma practices and streamlined hardware testing and integration, such as assembling major hardware elements before shipping to the Kennedy Space Center for launch operations. This paper provides top-level details for several cost saving initiatives, including both process and product improvements that will result in space transportation systems that are designed with operations efficiencies in mind. The Engineering Directorate provides both the intellectual capital embodied in an experienced workforce and unique facilities in which to validate the information technology tools that allow a nationwide team to collaboratively connect across miles that separate them and the engineering disciplines that integrate various piece parts into a whole system. As NASA transforms ground-based operations, it also is transitioning its workforce from an era of intense hands-on labor to a new one of mechanized conveniences and robust hardware with simpler interfaces. Ensuring that space exploration is on sound footing requires that operations efficiencies be designed into the transportation system and implemented in the development stage. Applying experience gained through decades of ground and space op'erations, while using value-added processes and modern business and engineering tools, is the philosophy upon which a new era of exploration will be built to solve some of the most pressing exploration challenges today -- namely, safety, reliability, and affordability.

Dumbacher, Daniel L.↗
NASA NTRS2022

Flight Software Dictionary Development for the Mars2020 Rover

The Mars2020 project, developed and operated by the Jet Propulsion Laboratory (JPL), successfully landed the Perseverance rover and its flying companion Ingenuity on the surface of Mars on February 18th 2021. Perseverance combines heritage and cutting-edge flight software and hardware to accomplish crucial mission requirements related to Martian surface sampling. The design, development, and operation of NASA’s large strategic science missions require the ability to communicate spacecraft capabilities to hundreds of engineers across multiple disciplines. The interaction between flight and ground software development, Verification and Validation (V&V), Assembly, Test, and Launch Operations (ATLO), and management each demand quick understanding of unique slices of information for each discipline. This information includes the current capabilities of the flight system as well as future capabilities and their status as they are developed and tested. Despite the fundamental and critical nature of this information, the flight software dictionaries used to track it are a stumbling block for many projects. These dictionaries provide the cornerstone for the interpretation of data sent from the spacecraft, allowing for quick comprehension by engineers on the ground. During both spacecraft development and operations, flight software dictionary management includes significant challenges due to the large number of interfacing systems and the subtle yet distinct needs of each.The engineering of flight software dictionaries for Mars2020 had numerous challenges, most-notably: parallel dictionary development to support simultaneous separate flight software build campaigns for each mission phase (cruise and surface), managing requests for operations-enabling information without perturbing the heritage interface with the rover, and the introduction of new tools by the dictionary stakeholders that forced the dictionary team to innovate and redesign the heritage tool chain. These challenges generated guiding principles for the dictionary development effort: emphasize coding best practices and unit testing in the dictionary code development tool chain, use institutionally provided COTS (commercial-off-the-shelf) tools whenever possible, and maintain the heritage flight-ground interface all while advancing operations-enabling information via a loosely coupled interface.Throughout development and operations, the Mars2020 dictionary toolchain included IBM DOORS Next Generation, GitHub, Microsoft Excel, Docker, Jenkins, and a significant custom-built Python codebase. Significant interfaces included JPL’s command and control software, heritage flight software team tools and processes, and the many cloud-based ground tools developed for the mission.This paper will discuss the requirements for the Mars2020 dictionary development, the development team’s response to those requirements, lessons learned throughout the process, steps taken towards automated deliveries and continuous integration of stakeholder inputs, potential toolchain improvements for Mars2020, and key takeaways that could be applied to future missions.

Pyrzak, Guy↗
NASA NTRS2010

The Process of the Development of an Operator

On the job training is where new employees called operators can start gaining knowledge on what they will be working on during their time in JSC. In these lessons I learned different things that are important ranging from thermal systems to electrical systems. While doing OJT classes the student will learn how to use a portable computer system which has displays that I also helped edit and clean up. The way you can also learn is by reading system briefs which describes the different systems. Due to the fact of a possible change in the ISS I updated a systems brief so that it can be relevant to what is actually on the space station. I was given a task that will help develop my skills and make myself better prepared for my future in the work field. The project that I worked on had me pulling real time data from the International Space Station. The Data I obtained from the space station will be correlated to battery performance. The group I will be working which is called REBA and we will take the telemetry and evaluate the data. I will be working with my mentor Ben Chislom and co-op Tyler along with the Pro team. They then will put this data into a graph so that they can get the discrepancies and find a way to improve the battery performance. The first weeks I read familiarization books that informed me how the ISS works, how it was built, and the systems that are used to keep the station working. This project is going to benefit NASA by finding out how electricity is being used on the ISS and enabling us to see how it can be used more efficiently. This way we can operate the ISS without wasting power. While conducting research that goes on inside the space station knowing all electricity is being used efficiently.

Banks, Terrence↗
NASA NTRS2018

Initial Approach to Collect Small Unmanned Aircraft System Off-Nominal Operational Situations Data

NASA is developing the Unmanned Aircraft System Traffic Management research platform to safely integrate small unmanned aircraft operations in large-scale at low-altitudes. As a part of this effort, small unmanned aircraft system off-nominal operational situations data collection process has been developed to take lessons learned and to reinforce operational compliance. In this paper, descriptions of variables used for digital data collection and an online report form for collection of observational data from the operators (contextual data) are provided. They are used to collect off-nominal data from the Unmanned Aircraft System Traffic Management National Campaign in 2017. The digital data show that 2 out of 118 campaign operations (1.7%) encountered loss of navigation. Since the campaign aircraft used Global Positioning System for navigation, it is likely that unobstructed view of the sky at the campaign locations contributed to this small number. Also, 4 out of 47 operations (8.5%) encountered loss of communications. A relatively short distance between ground control system and aircraft, ranging from 2300 feet to 4200 feet, likely contributed to this small number. There was no data to identify the loss of communications condition, aircraft received signal strength, for the remaining 71 operations suggesting that some operators may not be monitoring unmanned aircraft communications system performance or monitoring it with different parameters. For the contextual data, due to the low number of total reports during the campaign, no significant trends emerged. This is an initial attempt to collect contextual data from small unmanned aircraft operators about off-nominal situations, and changes will be made to the future data collection to improve the amount and quality of the information.

unmanned aviation systems traffic management (UTM)↗
NASA NTRS2018

Initial Approach to Collect Small Unmanned Aircraft System Off-Nominal Operational Situations Data

NASA is developing the Unmanned Aircraft System Traffic Management research platform to safely integrate small unmanned aircraft operations in large-scale at low-altitudes. As a part of this effort, small unmanned aircraft system off-nominal operational situations data collection process has been developed to take lessons learned and to reinforce operational compliance. In this paper, descriptions of variables used for digital data collection and an online report form for collection of observational data from the operators (contextual data) are provided. They are used to collect off-nominal data from the Unmanned Aircraft System Traffic Management National Campaign in 2017. The digital data show that 2 out of 118 campaign operations (1.7%) encountered loss of navigation. Since the campaign aircraft used Global Positioning System for navigation, it is likely that unobstructed view of the sky at the campaign locations contributed to this small number. Also, 4 out of 47 operations (8.5%) encountered loss of communications. A relatively short distance between ground control system and aircraft, ranging from 2300 feet to 4200 feet, likely contributed to this small number. There was no data to identify the loss of communications condition, aircraft received signal strength, for the remaining 71 operations suggesting that some operators may not be monitoring unmanned aircraft communications system performance or monitoring it with different parameters. For the contextual data, due to the low number of total reports during the campaign, no significant trends emerged. This is an initial attempt to collect contextual data from small unmanned aircraft operators about off-nominal situations, and changes will be made to the future data collection to improve the amount and quality of the information.

Jung, Jaewoo↗
NASA NTRS2017

Understanding the International Space Station Crew Perspective following Long-Duration Missions through Data Analytics & Visualization of Crew Feedback

The International Space Station (ISS) first became a home and research laboratory for NASA and International Partner crewmembers over 16 years ago. Each ISS mission lasts approximately 6 months and consists of three to six crewmembers. After returning to Earth, most crewmembers participate in an extensive series of 30+ debriefs intended to further understand life onboard ISS and allow crews to reflect on their experiences. Examples of debrief data collected include ISS crew feedback about sleep, dining, payload science, scheduling and time planning, health & safety, and maintenance. The Flight Crew Integration (FCI) Operational Habitability (OpsHab) team, based at Johnson Space Center (JSC), is a small group of Human Factors engineers and one stenographer that has worked collaboratively with the NASA Astronaut office and ISS Program to collect, maintain, disseminate and analyze this data. The database provides an exceptional and unique resource for understanding the "crew perspective" on long duration space missions. Data is formatted and categorized to allow for ease of search, reporting, and ultimately trending, in order to understand lessons learned, recurring issues and efficiencies gained over time. Recently, the FCI OpsHab team began collaborating with the NASA JSC Knowledge Management team to provide analytical analysis and visualization of these over 75,000 crew comments in order to better ascertain the crew's perspective on long duration spaceflight and gain insight on changes over time. In this initial phase of study, a text mining framework was used to cluster similar comments and develop measures of similarity useful for identifying relevant topics affecting crew health or performance, locating similar comments when a particular issue or item of operational interest is identified, and providing search capabilities to identify information pertinent to future spaceflight systems and processes for things like procedure development and training. In addition, the comments were scored for sentiment using a polarity scoring algorithm to identify both positive and negative comments for particular groups and clusters, allowing the team to make analytically informed decisions regarding future hardware and operating procedures. The use of polarity scoring with time series analysis was used to provide insight into how crew health and habitability is changing throughout various spaceflight increments or the station lifecycle as a whole. Finally, a visualization framework was developed to address the needs of the end users to search for and analyze comments by user, category or mission. This paper will discuss how the use of an analytical framework in conjunction with the current human interface, improved the understanding of crew perspective and shortened the time for analysis allowing for more informed decisions and rapid development of improvements. These methods are significantly optimizing the way that this valuable data can be assessed and applied to current and future spaceflight design and development. This collaboration allows the FCI OpsHab team to effectively analyze and share data in a more automated and timely fashion. Trends are no longer derived manually and can be illustrated effectively and accurately with these evolving techniques to an ever growing group of human spaceflight end users.

Bryant, Cody↗
NASA NTRS2019

Trends in Human Spaceflight: Failure Tolerance, High Reliability and Correlated Failure History

In a half century of human spaceflight, NASA has continuously refined agency safety and reliability requirements in response to mission demands, critical failures, and technology development. Early spacecraft, including Mercury, Gemini and Apollo vehicles, were highly reliant on dissimilar redundancy and demonstrated test margins. Later programs, such as the reusable Space Transportation System (STS) and International Space Station (ISS), introduced probabilistic studies and isolated two-failure tolerance to improve robustness at the expense of added complexity. More recently, the Orion Multi-Program Crew Vehicle (MPCV) program adopted universal single-failure tolerance with two categorical exceptions; Zero-Failure Tolerant (0FT) and Design for Minimum Risk (DFMR) hardware. Failure tolerance variances are defined and managed in accordance with agency human-rating requirements, and require concurrence from program Technical Authorities (TA) as well as the MPCV Safety and Mission Assurance Safety and Engineering Review Panel (MSERP). To understand and reaffirm standards applied to Apollo, Space Shuttle and Orion vehicles, Orion and Deep Space Gateway Safety and Mission Assurance (S&MA) representatives conducted accelerated research to compare unique safety and reliability criteria against ground and flight anomalies, based on information contained in post-mission reports and the Problem Reporting and Corrective Action (PRACA) database. In some cases, high-profile failures and narrow escapes have reinforced decisions to maintain or adapt safety requirements. In others, empirical trends have highlighted the need for vigilance and innovative safety guidelines. Given the inability to achieve absolute compliance with evolving safety and reliability requirements, the team conducted a targeted review of DFMR and 0FT propulsion elements within the framework of changing system design, inspection, materials and process developments to formulate conclusions on technological maturity, failure density, and net changes in safety risk. Based on the aggregate performance of high-reliability and failure-tolerant systems, the authors have attempted to establish best practices and guidelines to inform future program decisions. On a somewhat cautionary note, this study is not intended to direct a universal set of requirements for future missions based on prior lessons learned. Spacecraft safety is a multi-variable problem, and attempts to mitigate past failures will not guarantee future success. However, this assessment offers a retrospective review of policy changes, implementation and effectiveness. In the future, NASA, European Space Agency (ESA) and industry partners may benefit from a more robust correlation between requirements and performance, as space-faring nations work toward more challenging, complex and long-duration commercial and deep-space ventures.

Green, Carrie↗
NASA NTRS2005

Business Intelligence Modeling in Launch Operations

This technology project is to advance an integrated Planning and Management Simulation Model for evaluation of risks, costs, and reliability of launch systems from Earth to Orbit for Space Exploration. The approach builds on research done in the NASA ARC/KSC developed Virtual Test Bed (VTB) to integrate architectural, operations process, and mission simulations for the purpose of evaluating enterprise level strategies to reduce cost, improve systems operability, and reduce mission risks. The objectives are to understand the interdependency of architecture and process on recurring launch cost of operations, provide management a tool for assessing systems safety and dependability versus cost, and leverage lessons learned and empirical models from Shuttle and International Space Station to validate models applied to Exploration. The systems-of-systems concept is built to balance the conflicting objectives of safety, reliability, and process strategy in order to achieve long term sustainability. A planning and analysis test bed is needed for evaluation of enterprise level options and strategies for transit and launch systems as well as surface and orbital systems. This environment can also support agency simulation .based acquisition process objectives. The technology development approach is based on the collaborative effort set forth in the VTB's integrating operations. process models, systems and environment models, and cost models as a comprehensive disciplined enterprise analysis environment. Significant emphasis is being placed on adapting root cause from existing Shuttle operations to exploration. Technical challenges include cost model validation, integration of parametric models with discrete event process and systems simulations. and large-scale simulation integration. The enterprise architecture is required for coherent integration of systems models. It will also require a plan for evolution over the life of the program. The proposed technology will produce long-term benefits in support of the NASA objectives for simulation based acquisition, will improve the ability to assess architectural options verses safety/risk for future exploration systems, and will facilitate incorporation of operability as a systems design consideration, reducing overall life cycle cost for future systems. The future of business intelligence of space exploration will focus on the intelligent system-of-systems real-time enterprise. In present business intelligence, a number of technologies that are most relevant to space exploration are experiencing the greatest change. Emerging patterns of set of processes rather than organizational units leading to end-to-end automation is becoming a major objective of enterprise information technology. The cost element is a leading factor of future exploration systems.

Bardina, Jorge E.↗
NASA NTRS2007

Shuttle Entry Imaging Using Infrared Thermography

During the Columbia Accident Investigation, imaging teams supporting debris shedding analysis were hampered by poor entry image quality and the general lack of information on optical signatures associated with a nominal Shuttle entry. After the accident, recommendations were made to NASA management to develop and maintain a state-of-the-art imagery database for Shuttle engineering performance assessments and to improve entry imaging capability to support anomaly and contingency analysis during a mission. As a result, the Space Shuttle Program sponsored an observation campaign to qualitatively characterize a nominal Shuttle entry over the widest possible Mach number range. The initial objectives focused on an assessment of capability to identify/resolve debris liberated from the Shuttle during entry, characterization of potential anomalous events associated with RCS jet firings and unusual phenomenon associated with the plasma trail. The aeroheating technical community viewed the Space Shuttle Program sponsored activity as an opportunity to influence the observation objectives and incrementally demonstrate key elements of a quantitative spatially resolved temperature measurement capability over a series of flights. One long-term desire of the Shuttle engineering community is to calibrate boundary layer transition prediction methodologies that are presently part of the Shuttle damage assessment process using flight data provided by a controlled Shuttle flight experiment. Quantitative global imaging may offer a complementary method of data collection to more traditional methods such as surface thermocouples. This paper reviews the process used by the engineering community to influence data collection methods and analysis of global infrared images of the Shuttle obtained during hypersonic entry. Emphasis is placed upon airborne imaging assets sponsored by the Shuttle program during Return to Flight. Visual and IR entry imagery were obtained with available airborne imaging platforms used within DoD along with agency assets developed and optimized for use during Shuttle ascent to demonstrate capability (i.e., tracking, acquisition of multispectral data, spatial resolution) and identify system limitations (i.e., radiance modeling, saturation) using state-of-the-art imaging instrumentation and communication systems. Global infrared intensity data have been transformed to temperature by comparison to Shuttle flight thermocouple data. Reasonable agreement is found between the flight thermography images and numerical prediction. A discussion of lessons learned and potential application to a potential Shuttle boundary layer transition flight test is presented.

Horvath, Thomas↗
NASA NTRS2001

Automating Trend Analysis for Spacecraft Constellations

Spacecraft trend analysis is a vital mission operations function performed by satellite controllers and engineers, who perform detailed analyses of engineering telemetry data to diagnose subsystem faults and to detect trends that may potentially lead to degraded subsystem performance or failure in the future. It is this latter function that is of greatest importance, for careful trending can often predict or detect events that may lead to a spacecraft's entry into safe-hold. Early prediction and detection of such events could result in the avoidance of, or rapid return to service from, spacecraft safing, which not only results in reduced recovery costs but also in a higher overall level of service for the satellite system. Contemporary spacecraft trending activities are manually intensive and are primarily performed diagnostically after a fault occurs, rather than proactively to predict its occurrence. They also tend to rely on information systems and software that are oudated when compared to current technologies. When coupled with the fact that flight operations teams often have limited resources, proactive trending opportunities are limited, and detailed trend analysis is often reserved for critical responses to safe holds or other on-orbit events such as maneuvers. While the contemporary trend analysis approach has sufficed for current single-spacecraft operations, it will be unfeasible for NASA's planned and proposed space science constellations. Missions such as the Dynamics, Reconnection and Configuration Observatory (DRACO), for example, are planning to launch as many as 100 'nanospacecraft' to form a homogenous constellation. A simple extrapolation of resources and manpower based on single-spacecraft operations suggests that trending for such a large spacecraft fleet will be unmanageable, unwieldy, and cost-prohibitive. It is therefore imperative that an approach to automating the spacecraft trend analysis function be studied, developed, and applied to missions such as DRACO with the intent that mission operations costs be significantly reduced. The goal of the Constellation Spacecraft Trend Analysis Toolkit (CSTAT) project is to serve as the pathfinder for a fully automated trending system to support spacecraft constellations. The development approach to be taken is evolutionary. In the first year of the project, the intent is to significantly advance the state of the art in current trending systems through improved functionality and increased automation. In the second year, the intent is to add an expert system shell, likely through the adaptation of an existing commercial-off-the-shelf (COTS) or government-off-the-shelf (GOTS) tool to implement some level of the trending intelligence that humans currently provide in manual operations. In the third year, the intent is to infuse the resulting technology into a near-term constellation or formation-flying mission to test it and gain experience in automated trending. The lessons learned from the real missions operations experience will then be used to improve the system, and to ultimately incorporate it into a fully autonomous, closed-loop mission operations system that is truly capable of supporting large constellations. In this paper, the process of automating trend analysis for spacecraft constellations will be addressed. First, the results of a survey on automation in spacecraft mission operations in general, and in trending systems in particular will be presented to provide an overview of the current state of the art. Next, a rule-based model for implementing intelligent spacecraft subsystem trending will be then presented, followed by a survey of existing COTS/GOTS tools that could be adapted for implementing such a model. The baseline design and architecture of the CSTAT system will be presented. Finally, some results obtained from initial software tests and demonstrations will be presented.

Davis, George↗
NASA NTRSDate not supplied

A Model-Based Systems Engineering Journey to Developing a Concept of Operations

Starting in 2017, NASA’s Human Research Program (HRP) Exploration Medical Capability (ExMC) element began a systems engineering transition from traditional, document-centric development to model-centric development when defining its foundation medical systems. These foundation medical systems define a Concept of Operations (ConOps) and identify the generic requirements for a medical system based on assumptions about a generic crew and mission environments and guidance from NASA standards (e.g., Medical “Levels of Care”). By making the transition, ExMC intends to improve communication among stakeholders about foundation medical system requirements and content. In addition, this transition will enable ExMC to lower both development and crew treatment risks for future, mission-specific medical systems. ExMC followed a Model Based Systems Engineering (MBSE) paradigm when developing the foundation medical systems. A model-based approach provides several advantages over a traditional, document-centric approach. First, when Systems Engineers (SE) develop diagrams in a model using a standard modeling language, they produce information dense pictures that facilitate understanding much more efficiently with less room for misinterpretation than text. Second, due to the evolving nature of projects, documentation becomes out of date the minute it is published. This can result in people making decisions based on information that is no longer current, especially if they are referencing a locally-stored copy of a document. A model, on the other hand, is always up to date with the latest approved changes and information. It serves as a single point of truth. Third, a model-centric approach centralizes all important information in one place. Rather than having to flip through separate ConOps documents, design specifications, requirements specifications, and the like to coordinate information, a model captures the content in one, integrated spot. This integration makes tracing information from end-to-end easier with greater reliability. The ExMC Systems Engineering Lifecycle follows a well-defined process. ExMC Systems Engineers perform all major steps of the process, regardless of the development methodology. One of the first steps in the process is developing the ConOps that describes the operation of the system from the point of view of the users. It includes a list of the users and their needs, the goals of the medical system, key assumptions about the system, and definitions of the medical system’s operational environments. For this development effort, ExMC chose to replace the traditional text-based ConOps document with a model. While the decision to change the development workflow was not difficult, implementing the structural and organizational workflows were. It required showing ExMC’s users, most of whom are not Systems Engineers, how the information they require would be presented in the model and to gain their acceptance of this approach. This paper documents key lessons learned during the ConOps transformation by focusing on how the model represents information, the agile workflow used by SEs when developing the model and how it integrates into a project plan, how leadership influenced key users to accept the transformation, and how the users interact with the model information.

Jeffrey Robert Cohen↗
NASA NTRS2013

NASA Software Engineering Benchmarking Study

To identify best practices for the improvement of software engineering on projects, NASA's Offices of Chief Engineer (OCE) and Safety and Mission Assurance (OSMA) formed a team led by Heather Rarick and Sally Godfrey to conduct this benchmarking study. The primary goals of the study are to identify best practices that: Improve the management and technical development of software intensive systems; Have a track record of successful deployment by aerospace industries, universities [including research and development (R&D) laboratories], and defense services, as well as NASA's own component Centers; and Identify candidate solutions for NASA's software issues. Beginning in the late fall of 2010, focus topics were chosen and interview questions were developed, based on the NASA top software challenges. Between February 2011 and November 2011, the Benchmark Team interviewed a total of 18 organizations, consisting of five NASA Centers, five industry organizations, four defense services organizations, and four university or university R and D laboratory organizations. A software assurance representative also participated in each of the interviews to focus on assurance and software safety best practices. Interviewees provided a wealth of information on each topic area that included: software policy, software acquisition, software assurance, testing, training, maintaining rigor in small projects, metrics, and use of the Capability Maturity Model Integration (CMMI) framework, as well as a number of special topics that came up in the discussions. NASA's software engineering practices compared favorably with the external organizations in most benchmark areas, but in every topic, there were ways in which NASA could improve its practices. Compared to defense services organizations and some of the industry organizations, one of NASA's notable weaknesses involved communication with contractors regarding its policies and requirements for acquired software. One of NASA's strengths was its software assurance practices, which seemed to rate well in comparison to the other organizational groups and also seemed to include a larger scope of activities. An unexpected benefit of the software benchmarking study was the identification of many opportunities for collaboration in areas including metrics, training, sharing of CMMI experiences and resources such as instructors and CMMI Lead Appraisers, and even sharing of assets such as documented processes. A further unexpected benefit of the study was the feedback on NASA practices that was received from some of the organizations interviewed. From that feedback, other potential areas where NASA could improve were highlighted, such as accuracy of software cost estimation and budgetary practices. The detailed report contains discussion of the practices noted in each of the topic areas, as well as a summary of observations and recommendations from each of the topic areas. The resulting 24 recommendations from the topic areas were then consolidated to eliminate duplication and culled into a set of 14 suggested actionable recommendations. This final set of actionable recommendations, listed below, are items that can be implemented to improve NASA's software engineering practices and to help address many of the items that were listed in the NASA top software engineering issues. 1. Develop and implement standard contract language for software procurements. 2. Advance accurate and trusted software cost estimates for both procured and in-house software and improve the capture of actual cost data to facilitate further improvements. 3. Establish a consistent set of objectives and expectations, specifically types of metrics at the Agency level, so key trends and models can be identified and used to continuously improve software processes and each software development effort. 4. Maintain the CMMI Maturity Level requirement for critical NASA projects and use CMMI to measure organizations developing software for NASA. 5.onsolidate, collect and, if needed, develop common processes principles and other assets across the Agency in order to provide more consistency in software development and acquisition practices and to reduce the overall cost of maintaining or increasing current NASA CMMI maturity levels. 6. Provide additional support for small projects that includes: (a) guidance for appropriate tailoring of requirements for small projects, (b) availability of suitable tools, including support tool set-up and training, and (c) training for small project personnel, assurance personnel and technical authorities on the acceptable options for tailoring requirements and performing assurance on small projects. 7. Develop software training classes for the more experienced software engineers using on-line training, videos, or small separate modules of training that can be accommodated as needed throughout a project. 8. Create guidelines to structure non-classroom training opportunities such as mentoring, peer reviews, lessons learned sessions, and on-the-job training. 9. Develop a set of predictive software defect data and a process for assessing software testing metric data against it. 10. Assess Agency-wide licenses for commonly used software tools. 11. Fill the knowledge gap in common software engineering practices for new hires and co-ops.12. Work through the Science, Technology, Engineering and Mathematics (STEM) program with universities in strengthening education in the use of common software engineering practices and standards. 13. Follow up this benchmark study with a deeper look into what both internal and external organizations perceive as the scope of software assurance, the value they expect to obtain from it, and the shortcomings they experience in the current practice. 14. Continue interactions with external software engineering environment through collaborations, knowledge sharing, and benchmarking.

Rarick, Heather L.↗