Onboard data management
Configurations and functions of onboard data processing for space shuttles
Poupard, R. E.↗
SEARCH · Search NASA
Results for “configuration management”
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.
Digital Model-Based Engineering: Expectations, Prerequisites, and Challenges of Infusion
Digital model-based engineering (DMbE) is the use of digital artifacts, digital environments, and digital tools in the performance of engineering functions. DMbE is intended to allow an organization to progress from documentation-based engineering methods to digital methods that may provide greater flexibility, agility, and efficiency. The term 'DMbE' was developed as part of an effort by the Model-Based Systems Engineering (MBSE) Infusion Task team to identify what government organizations might expect in the course of moving to or infusing MBSE into their organizations. The Task team was established by the Interagency Working Group on Engineering Complex Systems, an informal collaboration among government systems engineering organizations. This Technical Memorandum (TM) discusses the work of the MBSE Infusion Task team to date. The Task team identified prerequisites, expectations, initial challenges, and recommendations for areas of study to pursue, as well as examples of efforts already in progress. The team identified the following five expectations associated with DMbE infusion, discussed further in this TM: (1) Informed decision making through increased transparency, and greater insight. (2) Enhanced communication. (3) Increased understanding for greater flexibility/adaptability in design. (4) Increased confidence that the capability will perform as expected. (5) Increased efficiency. The team identified the following seven challenges an organization might encounter when looking to infuse DMbE: (1) Assessing value added to the organization. Not all DMbE practices will be applicable to every situation in every organization, and not all implementations will have positive results. (2) Overcoming organizational and cultural hurdles. (3) Adopting contractual practices and technical data management. (4) Redefining configuration management. The DMbE environment changes the range of configuration information to be managed to include performance and design models, database objects, as well as more traditional book-form objects and formats. (5) Developing information technology (IT) infrastructure. Approaches to implementing critical, enabling IT infrastructure capabilities must be flexible, reconfigurable, and updatable. (6) Ensuring security of the single source of truth (7) Potential overreliance on quantitative data over qualitative data. Executable/ computational models and simulations generally incorporate and generate quantitative vice qualitative data. The Task team also developed several recommendations for government, academia, and industry, as discussed in this TM. The Task team recommends continuing beyond this initial work to further develop the means of implementing DMbE and to look for opportunities to collaborate and share best practices.
Hale, J. P.↗
Multiplexer/Demultiplexer Loading Tool (MDMLT)
The purpose of the MDMLT is to improve the reliability and speed of loading multiplexers/demultiplexers (MDMs) in the Software Development and Integration Laboratory (SDIL) by automating the configuration management (CM) of the loads in the MDMs, automating the loading procedure, and providing the capability to load multiple or all MDMs concurrently. This loading may be accomplished in parallel, or single MDMs (remote). The MDMLT is a Web-based tool that is capable of loading the entire International Space Station (ISS) MDM configuration in parallel. It is able to load Flight Equivalent Units (FEUs), enhanced, standard, and prototype MDMs as well as both EEPROM (Electrically Erasable Programmable Read-Only Memory) and SSMMU (Solid State Mass Memory Unit) (MASS Memory). This software has extensive configuration management to track loading history, and the performance improvement means of loading the entire ISS MDM configuration of 49 MDMs in approximately 30 minutes, as opposed to 36 hours, which is what it took previously utilizing the flight method of S-Band uplink. The laptop version recently added to the MDMLT suite allows remote lab loading with the CM of information entered into a common database when it is reconnected to the network. This allows the program to reconfigure the test rigs quickly between shifts, allowing the lab to support a variety of onboard configurations during a single day, based on upcoming or current missions. The MDMLT Computer Software Configuration Item (CSCI) supports a Web-based command and control interface to the user. An interface to the SDIL File Transfer Protocol (FTP) server is supported to import Integrated Flight Loads (IFLs) and Internal Product Release Notes (IPRNs) into the database. An interface to the Monitor and Control System (MCS) is supported to control the power state, and to enable or disable the debug port of the MDMs to be loaded. Two direct interfaces to the MDM are supported: a serial interface (debug port) to receive MDM memory dump data and the calculated checksum, and the Small Computer System Interface (SCSI) to transfer load files to MDMs with hard disks. File transfer from the MDM Loading Tool to EEPROM within the MDM is performed via the MILSTD- 1553 bus, making use of the Real- Time Input/Output Processors (RTIOP) when using the rig-based MDMLT, and via a bus box when using the laptop MDMLT. The bus box is a cost-effective alternative to PC-1553 cards for the laptop. It is noted that this system can be modified and adapted to any avionic laboratory for spacecraft computer loading, ship avionics, or aircraft avionics where multiple configurations and strong configuration management of software/firmware loads are required.
Brewer, Lenox Allen↗
Lightning Mapper Sensor Lens Assembly S.O. 5459: Project Management Plan
Kaiser Electro-Optics, Inc. (KEO) has developed this Project Management Plan for the Lightning Mapper Sensor (LMS) program. KEO has integrated a team of experts in a structured program management organization to meet the needs of the LMS program. The project plan discusses KEO's approach to critical program elements including Program Management, Quality Assurance, Configuration Management, and Schedule.
Zeidler, Janet↗
Apollo experience report: Flight-control data needs, terminal display devices, and ground system configuration requirements
The development of flight-control facilities for the Apollo program is reviewed from the viewpoint of the user organization. These facilities are treated in three categories: data systems, ground-based display and control systems, and configuration management. The effects of certain Apollo program factors on the selection, sizing, and configuration management of these systems are discussed. Recommendations are made regarding improvement of the systems and the reduction of system sensitivity to the program factors.
Hoover, R. A.↗
MiniDAQ-3: Providing concurrent independent subdetector data-taking on CMS production DAQ resources
The data acquisition (DAQ) of the Compact Muon Solenoid (CMS) experiment at CERN, collects data for events accepted by the Level-1 Trigger from the different detector systems and assembles them in an event builder prior to making them available for further selection in the High Level Trigger, and finally storing the selected events for offline analysis. In addition to the central DAQ providing global acquisition functionality, several separate, so-called “MiniDAQ” setups allow operating independent data acquisition runs using an arbitrary subset of the CMS subdetectors. During Run 2 of the LHC, MiniDAQ setups were running their event builder and High Level Trigger applications on dedicated resources, separate from those used for the central DAQ. This cleanly separated MiniDAQ setups from the central DAQ system, but also meant limited throughput and a fixed number of possible MiniDAQ setups. In Run 3, MiniDAQ-3 setups share production resources with the new central DAQ system, allowing each setup to operate at the maximum Level-1 rate thanks to the reuse of the resources and network bandwidth. Configuration management tools had to be significantly extended to support the synchronization of the DAQ configurations needed for the various setups. We report on the new configuration management features and on the first year of operational experience with the new MiniDAQ-3 system.
Amoiridis, Vassileios↗
Initial Analysis of Digitally Enabled Cooperative Operations in Class D Terminal Airspace
The primary contribution of this paper is an initial analysis of integrating digitally enabled cooperative operations (or digital operations for short) with Visual Flight Rules (VFR) and Instrument Flight Rules (IFR) operations in the terminal airspace around a Class D airport, specifically around Fort Worth Alliance airport (KAFW). Enabled by connected digital technologies and automated information exchange, digital operations as envisioned would utilize cooperative practices and operator-responsible separation to ensure safety. In the present study, three conflict management configurations for digital operations were analyzed: 1) centralized with a single instance of a conflict management service to model a scenario with only one fleet operator conducting digital operations or all fleet operators utilizing the same service, 2) federated with two different instances to model a scenario with two different fleet operators conducting digital operations, and 3) fully distributed with a different instance for each digital operation. In simulations in which recorded tracks for VFR and IFR operations were played back and digital operations were modeled that would nominally arrive at KAFW once every 20 minutes (given no conflict resolution maneuvers), there were one or fewer losses of separation (LOS) across the three conflict management configurations. The same result was seen in simulations in which digital operations would nominally arrive at KAFW once every 10 minutes. However, in simulations in which digital operations would nominally arrive at KAFW once every 5 minutes, the number of LOS ranged between six and ten. This highlights the need for follow-on research to investigate the extent to which additional capabilities for digital operations, such as complexity management and/or flow organization, may be needed.
digitally enabled cooperative operations, digital ↗
Initial Analysis of Digitally Enabled Cooperative Operations in Class D Terminal Airspace
The primary contribution of this paper is an initial analysis of integrating digitally enabled cooperative operations (or digital operations for short) with Visual Flight Rules (VFR) and Instrument Flight Rules (IFR) operations in the terminal airspace around a Class D airport, specifically around Fort Worth Alliance airport (KAFW). Enabled by connected digital technologies and automated information exchange, digital operations as envisioned would utilize cooperative practices and operator-responsible separation to ensure safety. In the present study, three conflict management configurations for digital operations were analyzed: 1) centralized with a single instance of a conflict management service to model a scenario with only one fleet operator conducting digital operations or all fleet operators utilizing the same service, 2) federated with two different instances to model a scenario with two different fleet operators conducting digital operations, and 3) fully distributed with a different instance for each digital operation. In simulations in which recorded tracks for VFR and IFR operations were played back and digital operations were modeled that would nominally arrive at KAFW once every 20 minutes (given no conflict resolution maneuvers), there were one or fewer losses of separation (LOS) across the three conflict management configurations. The same result was seen in simulations in which digital operations would nominally arrive at KAFW once every 10 minutes. However, in simulations in which digital operations would nominally arrive at KAFW once every 5 minutes, the number of LOS ranged between six and ten. This highlights the need for follow-on research to investigate the extent to which additional capabilities for digital operations, such as complexity management and/or flow organization, may be needed.
digitally enabled cooperative operations↗
Configuration and Data Management Process and the System Safety Professional
This article presents a discussion of the configuration management (CM) and the Data Management (DM) functions and provides a perspective of the importance of configuration and data management processes to the success of system safety activities. The article addresses the basic requirements of configuration and data management generally based on NASA configuration and data management policies and practices, although the concepts are likely to represent processes of any public or private organization's well-designed configuration and data management program.
Shivers, Charles Herbert↗
Making automated computer program documentation a feature of total system design
It is pointed out that in large-scale computer software systems, program documents are too often fraught with errors, out of date, poorly written, and sometimes nonexistent in whole or in part. The means are described by which many of these typical system documentation problems were overcome in a large and dynamic software project. A systems approach was employed which encompassed such items as: (1) configuration management; (2) standards and conventions; (3) collection of program information into central data banks; (4) interaction among executive, compiler, central data banks, and configuration management; and (5) automatic documentation. A complete description of the overall system is given.
Wolf, A. W.↗
SSC Engineering Analysis
A package for the automation of the Engineering Analysis (EA) process at the Stennis Space Center has been customized. It provides the ability to assign and track analysis tasks electronically, and electronically route a task for approval. It now provides a mechanism to keep these analyses under configuration management. It also allows the analysis to be stored and linked to the engineering data that is needed to perform the analysis (drawings, etc.). PTC s (Parametric Technology Corp o ration) Windchill product was customized to allow the EA to be created, routed, and maintained under configuration management. Using Infoengine Tasks, JSP (JavaServer Pages), Javascript, a user interface was created within the Windchill product that allows users to create EAs. Not only does this interface allow users to create and track EAs, but it plugs directly into the out-ofthe- box ability to associate these analyses with other relevant engineering data such as drawings. Also, using the Windchill workflow tool, the Design and Data Management System (DDMS) team created an electronic routing process based on the manual/informal approval process. The team also added the ability for users to notify and track notifications to individuals about the EA. Prior to the Engineering Analysis creation, there was no electronic way of creating and tracking these analyses. There was also a feature that was added that would allow users to track/log e-mail notifications of the EA.
Ryan, Harry↗
Predicting Airport Runway Configurations for Decision-Support Using Supervised Learning
One of the most challenging tasks for air traffic controllers is runway configuration management (RCM). It deals with the optimal selection of runways to operate on (for arrivals and departures) based on traffic, surface wind speed, wind direction, other environmental variables, noise constraints, and several other airport-specific factors. It affects the efficiency of the National Airspace System (NAS) and both surface and airspace operations can benefit from better understanding future runway configurations. In this paper, we present a comprehensive implementation of predictive models for runway configuration estimation from large volumes of historical data. Specifically, operational data from two full years (2018 and 2019) is collected, analyzed, and fused together to build the data product used in this work. The data set differs from prior work in the field in terms of its scope, resolution, and variety of factors collected and considered. Meteorological data is collected from two different sources – current weather conditions from METAR (Meteorological Terminal Aviation Routine Weather Report) and forecast weather conditions from Localized Aviation MOS Program (LAMP). Operational data from the Federal Aviation Administration (FAA) Aviation System Performance Metrics (ASPM) related to scheduled and actual number of arrivals and departures, average taxi times, etc. are collected. NASA’s Sherlock Data Warehouse is used to identify critical information such as go-arounds, and other events that might impact RCM decision-making. All data is collected and aggregated over 15-minute intervals throughout the two years. This provides a resolution like the timescales that might be necessary for runway configuration management decision-making. A variety of supervised learning algorithms are tested including Support Vector Machine, Random Forest, Gradient Boosting, etc. including tuning of the model hyperparameters. The modeling process is applied and presented on two representative U.S. airports – Charlotte Douglas International Airport (KCLT) and Denver International Airport (KDEN). The two airports present different levels of complexity in terms of the total number of configurations used and provide a balanced perspective on the generalizability of the developed approach to other airports in the NAS. Initial results are promising (F1 score of 0.91 at KCLT and 0.83 at KDEN) for data in the test set. The final paper will contain a comprehensive comparison between different models and model building strategies as well as further refined results. Most important predictors for each airport will be identified along with a discussion and recommendations on adapting the framework to other scenarios.
Tejas G Puranik↗
Towards Software Bill of Materials in the Nuclear Industry
Large, modern industrial facilities often incorporate thousands of digital assets in their operational technology. Regulated facilities, such as nuclear power plants (NPPs), maintain robust cybersecurity and configuration management programs that often use bills of materials (BOMs) for these assets, including make, model, and version of hardware, firmware, and software. However, these BOMs typically capture only first- or second-tier information provided by the original equipment manufacturer (OEM). Unfortunately, as indicated by the increasing number and sophistication of software supply chain attacks, this level of detail is insufficient for identifying all the potential vulnerabilities and risks in software applications. Software BOMs (SBOMs) provide detailed enumeration of components and dependencies within the product or devices, including firmware. SBOMs can be combined with vulnerability data sources and vendor vulnerability attestations to improve vulnerability management and enable rapid identification of affected components when new software vulnerabilities are discovered. Ideally, SBOMs are created by the OEM prior to installation. However, since this practice is not yet commonplace and since NPPs are typically slow to adopt new technology, most NPPs do not incorporate SBOMs into their asset or configuration management programs. Fortunately, SBOMs can be generated by NPPs on existing digital assets to provide further insight into risk management decisions. This report provides an overview of the current SBOM ecosystem and recommends guidance on how to get started in a “crawl, walk, run” manner to develop and implement a sustainable SBOM program for digital assets in an NPP.
22 GENERAL STUDIES OF NUCLEAR REACTORS↗
Digital Archive Issues from the Perspective of an Earth Science Data Producer
Contents include the following: Introduction. A Producer Perspective on Earth Science Data. Data Producers as Members of a Scientific Community. Some Unique Characteristics of Scientific Data. Spatial and Temporal Sampling for Earth (or Space) Science Data. The Influence of the Data Production System Architecture. The Spatial and Temporal Structures Underlying Earth Science Data. Earth Science Data File (or Relation) Schemas. Data Producer Configuration Management Complexities. The Topology of Earth Science Data Inventories. Some Thoughts on the User Perspective. Science Data User Communities. Spatial and Temporal Structure Needs of Different Users. User Spatial Objects. Data Search Services. Inventory Search. Parameter (Keyword) Search. Metadata Searches. Documentation Search. Secondary Index Search. Print Technology and Hypertext. Inter-Data Collection Configuration Management Issues. An Archive View. Producer Data Ingest and Production. User Data Searching and Distribution. Subsetting and Supersetting. Semantic Requirements for Data Interchange. Tentative Conclusions. An Object Oriented View of Archive Information Evolution. Scientific Data Archival Issues. A Perspective on the Future of Digital Archives for Scientific Data. References Index for this paper.
Barkstrom, Bruce R.↗
Directed Acyclic Graph Guidance Documentation
For over a decade, the National Aeronautics and Space Administration (NASA) has tracked and configuration-managed approximately 30 risks to astronaut health and performance that occur before, during and after spaceflight. The Human System Risk Board (HSRB), a Health and Medical Technical Authority (HMTA) Board at NASA Johnson Space Center, is the entity responsible for identifying, assessing, analyzing, and monitoring the official understanding of the risk or risk posture for each of the Human System Risks and determining – based on evaluation of the available evidence – when that risk posture changes. The ultimate purpose of tracking and researching these risks is to find ways to reduce the risk that astronaut crews face during spaceflight. Historically, research, development and operations relevant to one risk have been conducted in isolation from other risks; these individual risk ‘silos’ enabled initial characterization of each specific risk. In spaceflight however, the impact of exposure to risk for astronaut crews is cumulative, and not independent of exposures or other risks, as all the adverse effects of the spaceflight environment begin at launch, continue throughout the duration of the mission and in some cases across the lifetime of the crews. In January of 2020, the HSRB at NASA embarked on a pilot project designed to assess the potential value of causal diagramming as a tool to facilitate understanding these cumulative and interdependent effects as applied within Human System Risk management. This process uses directed acyclic graphs as a means of formalizing a shared mental model of the causal flow of risk among Risk Board stakeholders. Initially this model was to improve communication among those stakeholders, but the potential value exceeds communication alone. Formalization of the process for creating these causal diagrams will enable the creation of a composite risk network that is vetted by members of the NASA community and configuration managed. The causal diagrams are formulated as directed acyclic graphs (DAGs) to function as a type of knowledge graph for reference for the board and its stakeholders. This document outlines the pilot process, the standardized approaches, and guidance for risk custodian teams when creating and updating DAGs as a part of the NASA Human System Risk Management process.
Risk↗
Spaceflight Ground Support Equipment Reliability & System Safety Data
Presented were Reliability Analysis, consisting primarily of Failure Modes and Effects Analysis (FMEA), and System Safety Analysis, consisting of Preliminary Hazards Analysis (PHA), performed to ensure that the CoNNeCT (Communications, Navigation, and Networking re- Configurable Testbed) Flight System was safely and reliably operated during its Assembly, Integration and Test (AI&T) phase. A tailored approach to the NASA Ground Support Equipment (GSE) standard, NASA-STD-5005C, involving the application of the appropriate Requirements, S&MA discipline expertise, and a Configuration Management system (to retain a record of the analysis and documentation) were presented. Presented were System Block Diagrams of selected GSE and the corresponding FMEA, as well as the PHAs. Also discussed are the specific examples of the FMEAs and PHAs being used during the AI&T phase to drive modifications to the GSE (via "redlining" of test procedures, and the placement of warning stickers to protect the flight hardware) before being interfaced to the Flight System. These modifications were necessary because failure modes and hazards were identified during the analysis that had not been properly mitigated. Strict Configuration Management was applied to changes (whether due to upgrades or expired calibrations) in the GSE by revisiting the FMEAs and PHAs to reflect the latest System Block Diagrams and Bill Of Material. The CoNNeCT flight system has been successfully assembled, integrated, tested, and shipped to the launch site without incident. This demonstrates that the steps taken to safeguard the flight system when it was interfaced to the various GSE were successful.
Fernandez, Rene↗
Directed Acyclic Graphs: A Tool for Understanding the NASA Human Spaceflight System Risks - Human System Risk Board
For over a decade, the National Aeronautics and Space Administration (NASA) has tracked and configuration-managed approximately 30 risks to astronaut health and performance that occur before, during and after spaceflight. The Human System Risk Board (HSRB), a Health and Medical Technical Authority (HMTA) Board at NASA Johnson Space Center, is the entity responsible for identifying, assessing, analyzing, and monitoring the official understanding of the risk or risk posture for each of the Human System Risks and determining – based on evaluation of the available evidence – when that risk posture changes. The ultimate purpose of tracking and researching these risks is to find ways to reduce the risk that astronaut crews face during spaceflight. Historically, research, development and operations relevant to one risk have been conducted in isolation from other risks; these individual risk ‘silos’ enabled initial characterization of each specific risk. In spaceflight however, the impact of exposure to risk for astronaut crews is cumulative, and not independent of exposures or other risks, as all the adverse effects of the spaceflight environment begin at launch, continue throughout the duration of the mission and in some cases across the lifetime of the crews. In January of 2020, the HSRB at NASA embarked on a pilot project designed to assess the potential value of causal diagramming as a tool to facilitate understanding of these cumulative and interdependent effects as applied within Human System Risk management. This process uses directed acyclic graphs as a means of formalizing a shared mental model of the causal flow of risk among Risk Board stakeholders. Initially this model was to improve communication among those stakeholders, but the potential value exceeds communication alone. The causal diagrams are formulated as directed acyclic graphs (DAGs) to function as a type of knowledge graph for reference for the board and its stakeholders. This document is a sister document to NASA/TM 20220006812 Directed Acyclic Graph Guidance Documentation (1). In that document, the basic guidance for creating and standardizing directed acyclic graphs as tools for cross-risk analysis is provided. This document contains the initial configuration managed DAGs that were created as a result of applying those principles. These initial versions were accepted by the HSRB in January of 2022. Each of the Human System Risks are represented by a DAG that has been reviewed by the larger Human Health and Performance community at NASA including life scientists, physical scientists, physicians, nurses, pharmacists, exercise specialists and more. These results show the starting point for Human System Risk DAGs as shared mental models and communication aids across the boundaries of the various expertise needed to understand and mitigate the human risks in spaceflight. Because they are a starting point, each of these DAGs can be expected to change over time as new or refined evidence becomes available. The process for updating these DAGs can be found in the JSC-66705 Human System Risk Management Plan (2) that is publicly available on the NASA Technical Reports Server.
Erik L. Antonsen↗
Guidance and Control Software Project Data - Volume 1: Planning Documents
The Guidance and Control Software (GCS) project was the last in a series of software reliability studies conducted at Langley Research Center between 1977 and 1994. The technical results of the GCS project were recorded after the experiment was completed. Some of the support documentation produced as part of the experiment, however, is serving an unexpected role far beyond its original project context. Some of the software used as part of the GCS project was developed to conform to the RTCA/DO-178B software standard, "Software Considerations in Airborne Systems and Equipment Certification," used in the civil aviation industry. That standard requires extensive documentation throughout the software development life cycle, including plans, software requirements, design and source code, verification cases and results, and configuration management and quality control data. The project documentation that includes this information is open for public scrutiny without the legal or safety implications associated with comparable data from an avionics manufacturer. This public availability has afforded an opportunity to use the GCS project documents for DO-178B training. This report provides a brief overview of the GCS project, describes the 4-volume set of documents and the role they are playing in training, and includes the planning documents from the GCS project. Volume 1 contains five appendices: A. Plan for Software Aspects of Certification for the Guidance and Control Software Project; B. Software Development Standards for the Guidance and Control Software Project; C. Software Verification Plan for the Guidance and Control Software Project; D. Software Configuration Management Plan for the Guidance and Control Software Project; and E. Software Quality Assurance Activities.
Hayhurst, Kelly J.↗