Search NASA⌕ Search

SEARCH · Search NASA

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.

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

At least 145 records · Page 8

PHASM: A Toolkit for Creating AI Surrogate Models within Legacy Codebases

PHASM (“Parallel Hardware viA Surrogate Models”) is a software toolkit for creating AI-based surrogate models of scientific code. AI-based surrogate models are widely used for creating fast and inverse simulations. PHASM anticipates an additional future use case: adapting legacy code to modern hardware. While data centers are investing in heterogeneous hardware such as GPUs and FPGAs, many established scientific codebases remain unable to take advantage of the hardware’s higher parallelism without undergoing a costly rewrite. An alternative is to train a AI-based surrogate model to mimic computationally intensive functions in the code, and run the surrogate instead. PHASM formalizes a development lifecycle for such surrogate models, including discovering functions amenable to replacement with a surrogate model, predicting the resulting performance, identifying the function’s space of inputs and outputs, binding the model to the code, and managing model versions. A suite of software tools for facilitating these steps was written and validated against a set of model problems.

97 MATHEMATICS AND COMPUTING↗

Failure Assessment

Three questions to which software developers want accurate, precise answers are "How can the software system fail?", "mat bad things will happen if the software fails?t', and "How many failures will the software experience?". Numerous techniques have been devised to answer these questions; three of the best known are: 1) Software Fault Tree Analysis (SFTA) 2) Software Failure Modes, Effects, and Criticality Analysis (SFMECA 3) Software Fault/Failure Modeling. SFTA and SFMECA have been successfully used to analyze the flight software for a number of robotic planetary exploration missions, including Galileo, Cassini, and Deep Space 1. Given the increasing interest in reusing software components from mission to mission, one of us has developed techniques for reusing the corresponding portions of the SFTA and SFMECA, reducing the effort required to conduct these analyses. SFTA has also been shown to be effective in analyzing the security aspects of software systems; intrusion mechanisms and effects can easily be modeled using these techniques. The Bi- Directional Safety Analysis (BDSA) method combines a forward search (similar to SFMECA) from potential failure modes to their effects, with a backward search (similar to SFTA) from feasible hazards to the contributing causes of each hazard. BDSA offers an efficient way to identify latent failures. Recent work has extended BDSA to product-line applications such as flight-instrumentation displays and developed tool support for the reuse of the failure-analysis artifacts within a product line. BDSA has also been streamlined to support those projects having tight cost and/or schedule constraints for their failure analysis efforts. We discuss lessons learned from practice, describe available tools, and identi@ some future directions for the topic. A substantial amount of research has been devoted to estimating the number of failures that a software system will experience during test and operations, as well as the number of faults that have been inserted into that system during its development. One of us has found that the amount of structural change to a system during its development is strongly related to the number of faults inserted into it. Using techniques requiring no additional effort on the part of the development organization, the required measurements of structural evolution can be easily obtained from a development effort's configuration management system and readily transformed into an estimate of fault content. So far, structure-fault relationships have been identified for source code; current work seeks to examine artifacts available earlier in the lifecycle to determine if similar relationships between structure and fault content can be found. In particular, relationships between requirements change requests and the number of faults inserted into the implemented system would provide a significant improvement in our ability to control software quality during the early development phases.

fault tree↗

Experimental Data Curation at Large Instrument Facilities with Open Source Software

The National Synchrotron Light Source II operating at Brookhaven National Laboratory since 2014 for the US Department of Energy is one of the newest and brightest storage-ring synchrotron facility in the world. NSLS-II, like other facilities, provides pre-processing of the raw data and some analysis capabilities to its users. We describe the research collaborations and open source infrastructure developed at large instrument facilities such as NSLS-II for the purpose of curating high value scientific data along the early stages of the data lifecycle. Data acquisition and curation tasks include storing experiment configuration, detector metadata, raw data acquisition with infrastructure that converts proprietary instrument formats to industry standards. In addition, we describe a specific effort for discovering sample information at NSLS-II and tracing the provenance of analysis performed on acquired images. We show that curation tasks must be embedded into software along the data life cycle for effectiveness and ease of use, and that loosely defined collaborations evolve around shared open source tools. Finally we discuss best practices for experimental metadata capture in such facilities, data access and the new challenges of scale and complexity posed by AI-based discovery for the synthesis of new materials.

96 KNOWLEDGE MANAGEMENT AND PRESERVATION↗

Emerging technologies for V&V of ISHM software for space exploration

Systems1,2 required to exhibit high operational reliability often rely on some form of fault protection to recognize and respond to faults, preventing faults' escalation to catastrophic failures. Integrated System Health Management (ISHM) extends the functionality of fault protection to both scale to more complex systems (and systems of systems), and to maintain capability rather than just avert catastrophe. Forms of ISHM have been utilized to good effect in the maintenance phase of systems' total lifecycles (often referred to as 'condition-based mainte-nance'), but less so in a 'fault protection' role during actual operations. One of the impediments to such use lies in the challenges of verification, validation and certification of ISHM systems themselves. This paper makes the case that state-of-the-practice V&V and certification techniques will not suffice for emerging forms of ISHM systems; however, a number of maturing software engineering assurance technologies show particular promise for addressing these ISHM V&V challenges.

fault detection, isolation, and recovery↗

Data Service Provider Cost Estimation Tool

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

Fontaine, Kathy↗

Applied Space Systems Engineering: Manage Technical Data - Chapter 17

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

Kent, Peter↗

Astrobee: Completed, Current, and Future Research using Free Flying Robots on the International Space Station

After four years on the International Space Station (ISS), the Astrobee Research Facility, has completed over 130 Test Sessions logging over 1000 hours of operations. Managed by the NASA ISS Program OZ office and supported by NASA Ames Research Center (ARC) in California, the Astrobee Team maintains three identical free-flying Astrobee robots for research on the ISS. As a technology demonstration platform, the Astrobee Robots are available for Guest Scientists to use for a spectrum of research capabilities. Astrobee, propelled by battery-operated fans, is designed to autonomously operate throughout most of the USOS (US Orbital Segment), with the objective of minimizing astronaut support. Astrobee carries a suite of six cameras, a two degree-of-freedom (DOF) arm with a gripper that can grasp ISS handrails and other objects, and three payload bays that provide power and data for guest science hardware. Astrobee can autonomously execute hours-long flight plans or be teleoperated from the ground or by astronauts. While the Astrobee Team continues to improve mapping and autonomous flight capabilities, one of the main goals of Astrobee Robots is to provide research opportunities for Guest Scientists. The Astrobee Robot Software (ARS) makes extensive use of the open-source Robot Operating System (ROS). The ARS can be used interchangeably with an Astrobee Simulator or as Astrobee’s onboard software. ARS features include autonomous docking and perching, real-time teleoperations from the ground, plan based autonomous tasks, multi Astrobee communication, among other capabilities. Through simulation software and ground testing laboratories, the Astrobee Team is available to support Guest Scientists during development and testing and lead real-time ISS operations. Guest Scientists can participate in this research opportunity following the Guest Science Lifecycle (GSL) shown in Figure 1: Guest Science Lifecycle below. The Astrobee Team and Guest Scientists have complete research including Gecko materials studies, RFID and sound sensing capabilities, student Robotics Programming Challenges, and Free Flyer formation flight investigations. Current science with the Astrobee Robots includes Free Flyer self-toss studies, new docking capabilities, advanced mapping resolution capabilities, and high resolution panoramic imagery. Future Guest scientists and Astrobee Team research will focus on robotics applications for future NASA missions such as Gateway and Artemis and potential experiments involving human-robot interactions. This presentation will focus on four main subjects, 1) completed, current, and future planned research using the Astrobee robots, 2) how Guest Scientist get from conception to the ISS, 3) Astrobee Facility resources available for Guest Science ground testing and real-time ISS operations support, and 4) lessons learned from four years of ISS operations.

Astrobee↗

Comparative Assessment of Experimental Testing of Instrument with an Embedded Digital Device Using Model-Based and Conventional Methods

The use of digital equipment has not been widespread in U.S. nuclear facilities. A major contributing factor to this situation arises from regulatory concerns about common cause failures (CCFs) stemming from the use of identical software in redundant systems, questions as to how to quantify the reliability of software-based products, validity of tools that are used for software verification and validation (V&V), and the effectiveness of software QA procedures. Compounding the concerns are sporadic incidents of digital equipment malfunctions in nuclear power plants, including lockups resulting from software memory leaks, feedwater control malfunctions due to excessive traffic on Ethernet networks, software logic errors, and other problems leading to plant trips. Additionally, the limited amount of demonstrated research and a lack of industry consensus on quantitative software reliability methodologies has hindered the widespread adoption of digital I&C in the nuclear industry. In a recent Regulatory Issue Summary (RIS), the U.S. Nuclear Regulatory Commission (NRC) identified concerns about the impact of greater use of instrumentation and control (I&C) equipment with an embedded digital device (EDD) [1]. Specifically, the NRC staff states that increased use of such devices “may increase a facility’s vulnerability to a CCF” (i.e., common-cause failure). The prevailing NRC guidance regarding software CCF (SCCF) identifies two design attributes that are acceptable for eliminating CCF concerns: (1) diversity or (2) testability (specifically, 100% testability). Either solution can result in high costs and remaining licensing uncertainty (i.e., how much diversity is enough? how to ensure test coverage of every possible sequence of device states?). Consequently, many utilities and reactor designers have limited or avoided more extensive use of digital technology to minimize licensing, scheduling, and financial risk. Without development of cost effective qualification methods to satisfy regulatory requirements and address the potential for CCF vulnerability associated with EDDs, the nuclear power industry may not be able to realize the benefits of digital technology achieved by other industries. In order to address these challenges, the U.S. Department of Energy (DOE) is sponsoring this research to assess the prospect of CCF in digital I&C equipment. The purpose of the current research is to develop an effective approach employing science-based methods to resolve concerns about CCF vulnerability that serve to inhibit deployment of advanced instrumentation (e.g., sensors, actuators, microcontrollers) with EDDs in nuclear power applications. The research objectives address the challenge of establishing high levels of safety and reliability assurance needed for the qualification of EDDs (e.g., microprocessors, programmable logic devices) that are subject to software design faults, complex failure modes, and CCF vulnerability. Specific objectives are: (1) assess the regulatory context for treatment of CCF vulnerability a graded approach to their qualification, (3) develop and extend model-based testing methods to enable effective demonstration of whether devices are subject to CCF, which may arise from vulnerabilities introduced at any stage of the design lifecycle, (4) establish a cost-effective testing framework that incorporates automation and test scenario prioritization, and (5) demonstrate the qualification approach through selection and testing of candidate digital device(s). This report documents an assessment of the results from experimental testing of a representative instrument with an embedded digital device. The experiment serves as a proof-of-concept demonstration of a model-based testing (MBT) framework. The objective of MBT is to ensure that an EDD undergoes suitably comprehensive testing to establish that it is not subject to SCCF. The approach by which MBT accomplishes this objective is through development and application of an effective test suite that provides the appropriate coverage to detect the full range of postulated faults that may arise at the requirements, design, and code (implementation) level of the EDD software. The findings of the experiment involve the application of the MBT framework by Ohio State University (OSU) through testing of the selected demonstration instrument (i.e., the prototype smart pressure sensor developed by Virginia Commonwealth University, VCU). In addition, the experiment findings also involve application of a more conventional black-box testing approach that serves as a baseline against which the MBT methodology can be compared. The primary outcome documented in this report is the comparative analysis of the capabilities demonstrated for each method. The results of the analysis demonstrate clear benefits that arise from the MBT methodology. The comparison indicates greater effectiveness from the more comprehensive evidence available through MBT and enhanced efficiency achieved through automation within the MBT framework. The structure of the report addresses the approach and application of each test method as well as the comparative analysis of the experimental results. Chapter 2 gives a summary overview of the demonstration approach. Chapter 3 covers the baseline testing and Chapter 4 documents the model-based testing. Chapter 5 describes the findings of the comparative analysis and presents the conclusions that can be drawn about the effectiveness and efficiency of the MBT methodology.

47 OTHER INSTRUMENTATION↗

EVs@Scale High-Power Charging (HPC) Pillar Deep-Dive Technical Meeting

EVs@Scale Lab Consortium is addressing challenges, developing solutions, and enabling technologies for transportation electrification ecosystem. The consortium has five research pillars one of which focuses on high power charging (HPC). HPC pillar brings together hardware and software expertise, capabilities, and facilities related to high power EV charging, charge management, and grid integration. Deep-dive technical meetings are organized twice a year and provides an opportunity for more industry engagement and technical feedback for the national labs throughout the project lifecycle. High-Power Charging pillar has two active projects: (i) Next-Gen Profiles (NGP) and (ii) High-Power Electric Vehicle Charging Hub Integration Platform (eCHIP). This presentation summarizes the progress made in both projects during the past six months focusing on specific topics. There will be two deep-dive technical meetings twice a year. Every deep-dive meeting will focus on different aspects of the project progress.

ADVANCED PROPULSION SYSTEMS↗

Nov. 2024 EVs@Scale High-Power Charging Deep Dive Technical Meeting

EVs@Scale Lab Consortium is addressing challenges, developing solutions, and enabling technologies for transportation electrification ecosystem. The consortium has five research pillars one of which focuses on high power charging (HPC). HPC pillar brings together hardware and software expertise, capabilities, and facilities related to high power EV charging, charge management, and grid integration. Deep-dive technical meetings are organized twice a year and provides an opportunity for more industry engagement and technical feedback for the national labs throughout the project lifecycle. High-Power Charging pillar has two active projects: (i) Next-Gen Profiles (NGP) and (ii) High-Power Electric Vehicle Charging Hub Integration Platform (eCHIP). This presentation summarizes the progress made in both projects during the past six months focusing on specific topics. There will be two deep-dive technical meetings twice a year. Every deep-dive meeting will focus on different aspects of the project progress.

ADVANCED PROPULSION SYSTEMS,DIRECT ENERGY CONVERSI↗

Improving and Automating Building Model Data Exchange

There are many instances throughout a project’s lifecycle where there arises a need for quick and accurate risk assessment of building designs. For example, an unexpected design change during construction may necessitate structural engineers to perform a seismic risk assessment on analytical models of the updated building design using high fidelity structural analysis software, such as ANSYS or Abaqus. However, the efficiency of such workflows often depends upon the interoperability of architectural design software and structural analysis software. When the quality of this interoperability is lacking or even non-existent, the efficiency of virtual engineering workflows is hampered, which increases project costs. A McGraw Hill industry survey of professional users of Building Information Modeling (BIM) technologies found that there is high demand for BIM interoperability for structural analysis, but that the value/difficulty ratio is currently too low for practical use. There have been efforts by the academic community to facilitate model data exchange between the architectural design and structural analysis domains, but such solutions have not been widely adopted by industry, face technical challenges, and oftentimes are limited in applicability for users of various BIM software. Therefore, INL is developing capabilities to improve, automate, and generalize model data exchange between architectural BIM software (e.g., Revit) and structural analysis software (e.g., SAP2000, ANSYS). The goal is to help expedite and automate as much of the pre-processing step for creating analytical models in finite element analysis software as reasonably as possible. Such a "BIM-to-FEA" conversion tool should provide direct benefit to end-users through accuracy, automation, quick turn-around, and wide applicability. To generalize the application of this BIM-to-FEA conversion tool and increase its useability among the many different commercial BIM software currently used by industry, the program is being developed with the concept of openBIM. OpenBIM is the application of non-proprietary, open data standards that allow for BIM model data exchange in a format that is accessible, retainable, and useable for all users. The most widely used open, non-proprietary data exchange format for BIM is the Industry Foundation Classes (IFC) schema. IFC is developed by buildingSMART international and is ISO certified (ISO 16739-1:2018). The BIM-to-FEA conversion tool is being developed for compatibility with typical commercial building designs of steel framed structures. The tool is currently capable of importing architectural BIM data of framed building structures, recognizing and extracting the aspects of the model that are required for structural analysis, adjusting the connectivity of frame members, and finally exporting to an analytical model stored in the IFC format. The exported IFC analytical model can then be imported into various openBIM compliant software, such as SAP2000. Such capabilities have already been tested on commercial software, as shown above, and continue to be improved. Work is underway to test the conversion on various commercial BIM software, develop a user-friendly interface, incorporate the program into the broader DeepLynx data warehouse project being developed by INL, and to eventually open-source the tool for the benefit of the community. Future development of the tool envisions the ability for efficient iterative risk assessment of generative building designs, all within a workflow utilizing open-source tools. One such open-source tool will be MOOSE, an advanced finite element analysis tool developed at INL. The conversion tool will also branch out from typical commercial building designs and will aim to incorporate nuclear construction. The aim will be to convert both structural and non-structural components of nuclear facilities, such as curved concrete containment structures and piping systems, respectively.

97 MATHEMATICS AND COMPUTING↗

Real-Time Simulation of Ares I Launch Vehicle

The Ares Real-Time Environment for Modeling, Integration, and Simulation (ARTEMIS) has been developed for use by the Ares I launch vehicle System Integration Laboratory (SIL) at the Marshall Space Flight Center (MSFC). The primary purpose of the Ares SIL is to test the vehicle avionics hardware and software in a hardware-in-the-loop (HWIL) environment to certify that the integrated system is prepared for flight. ARTEMIS has been designed to be the real-time software backbone to stimulate all required Ares components through high-fidelity simulation. ARTEMIS has been designed to take full advantage of the advances in underlying computational power now available to support HWIL testing. A modular real-time design relying on a fully distributed computing architecture has been achieved. Two fundamental requirements drove ARTEMIS to pursue the use of high-fidelity simulation models in a real-time environment. First, ARTEMIS must be used to test a man-rated integrated avionics hardware and software system, thus requiring a wide variety of nominal and off-nominal simulation capabilities to certify system robustness. The second driving requirement - derived from a nationwide review of current state-of-the-art HWIL facilities - was that preserving digital model fidelity significantly reduced overall vehicle lifecycle cost by reducing testing time for certification runs and increasing flight tempo through an expanded operational envelope. These two driving requirements necessitated the use of high-fidelity models throughout the ARTEMIS simulation. The nature of the Ares mission profile imposed a variety of additional requirements on the ARTEMIS simulation. The Ares I vehicle is composed of multiple elements, including the First Stage Solid Rocket Booster (SRB), the Upper Stage powered by the J- 2X engine, the Orion Crew Exploration Vehicle (CEV) which houses the crew, the Launch Abort System (LAS), and various secondary elements that separate from the vehicle. At launch, the integrated vehicle stack is composed of these stages, and throughout the mission, various elements separate from the integrated stack and tumble back towards the earth. ARTEMIS must be capable of simulating the integrated stack through the flight as well as propagating each individual element after separation. In addition, abort sequences can lead to other unique configurations of the integrated stack as the timing and sequence of the stage separations are altered.

Tobbe, Patrick↗

On-demand Command and Control of ASTERIA with Cloud-based Ground Station Services

ASTERIA (Arcsecond Space Telescope Enabling Research in Astrophysics) was a 6-unit CubeSat technology demonstration mission that deployed from the International Space Station on November 20th, 2017. After successfully completing its 90-day primary mission that demonstrated arcsecond-level line-of-sight pointing and focal plane thermal stability for exoplanet detection, it entered an extended mission performing onboard software demonstrations to mature technology both in space and on the ground. One of the technologies was a completely cloud-based ground system leveraging Amazon Web Services (AWS) Ground Station service.Announced in December 2018 and launched in May 2019, AWS Ground Station is a fully managed ground station service that aims to reduce the overhead associated with developing and maintaining ground system infrastructure throughout the mission lifecycle. AWS Ground Station makes available the suite of features required for any ground system in support of low-Earth orbit (LEO) and medium-Earth Orbit (MEO) satellite operations on-demand and without setting up or maintaining long-term contracts. Charges are incurred on a per-minute basis for antenna usage during scheduled tracks. Support is available for S-band uplink and downlink, along with X-band narrowband and wideband downlink. Missions that use the service may reserve tracks with any licensed AWS Ground Station antennas located across each service region and have direct access to any AWS services in support of mission operations.The cloud-based architecture built around the AWS Ground Station service greatly enhanced ASTERIA mission operations by enabling end-to-end pass automation, on-demand contact scheduling and contingency planning, along with more efficient data downlink through station availability and station-to-station handovers. It incorporated open-source software, particularly NASA's AMMOS Instrument Toolkit (AIT) and Open Mission Control Technologies (OpenMCT), along with the AWS application programming interfaces (API) to the Ground Station, Elastic Compute Cloud (EC2) and Simple Storage Service (S3) services. After showcasing operability in August 2019, the team continued using and improving this novel ground system architecture until the end of mission in December 2019. This paper describes the cloud-based ground system, how it was designed, tested, and evaluated with an in-orbit spacecraft, the operational capabilities that it enabled, along with lessons learned and recommendations for future missions.

Fesq, Lorraine↗

On-demand Command and Control of ASTERIA with Cloud-based Ground Station Services

ASTERIA (Arcsecond Space Telescope Enabling Research in Astrophysics) was a 6-unit CubeSat technology demonstration mission that deployed from the International Space Station on November 20th, 2017. After successfully completing its 90-day primary mission that demonstrated arcsecond-level line-of-sight pointing and focal plane thermal stability for exoplanet detection, it entered an extended mission performing onboard software demonstrations to mature technology both in space and on the ground. One of the technologies was a completely cloud-based ground system leveraging Amazon Web Services (AWS) Ground Station service. Announced in December 2018 and launched in May 2019, AWS Ground Station is a fully managed ground station service that aims to reduce the overhead associated with developing and maintaining ground system infrastructure throughout the mission lifecycle. AWS Ground Station makes available the suite of features required for any ground system in support of low-Earth orbit (LEO) and medium-Earth Orbit (MEO) satellite operations on-demand and without setting up or maintaining long-term contracts. Charges are incurred on a per-minute basis for antenna usage during scheduled tracks. Support is available for S-band uplink and downlink, along with X-band narrowband and wideband downlink. Missions that use the service may reserve tracks with any licensed AWS Ground Station antennas located across each service region and have direct access to any AWS services in support of mission operations. The cloud-based architecture built around the AWS Ground Station service greatly enhanced ASTERIA mission operations by enabling end-to-end pass automation, on-demand contact scheduling and contingency planning, along with more efficient data downlink through station availability and station-tostation handovers. It incorporated open-source software, particularly NASA's AMMOS Instrument Toolkit (AIT) and Open Mission Control Technologies (OpenMCT), along with the AWS application programming interfaces (API) to the Ground Station, Elastic Compute Cloud (EC2) and Simple Storage Service (S3) services. After showcasing operability in August 2019, the team continued using and improving this novel ground system architecture until the end of mission in December 2019. This paper describes the cloud-based ground system, how it was designed, tested, and evaluated with an inorbit spacecraft, the operational capabilities that it enabled, along with lessons learned and recommendations for future missions.

Fesq, Lorraine↗

Integrating quantum computing resources into scientific HPC ecosystems

Quantum Computing (QC) offers significant potential to enhance scientific discovery in fields such as quantum chemistry, optimization, and artificial intelligence. Yet QC faces challenges due to the noisy intermediate-scale quantum era’s inherent external noise issues. Here, this paper discusses the integration of QC as a computational accelerator within classical scientific high-performance computing (HPC) systems. By leveraging a broad spectrum of simulators and hardware technologies, we propose a hardware-agnostic framework for augmenting classical HPC with QC capabilities. Drawing on the HPC expertise of the Oak Ridge National Laboratory (ORNL) and the HPC lifecycle management of the Department of Energy (DOE), our approach focuses on the strategic incorporation of QC capabilities and acceleration into existing scientific HPC workflows. This includes detailed analyses, benchmarks, and code optimization driven by the needs of the DOE and ORNL missions. Our comprehensive framework integrates hardware, software, workflows, and user interfaces to foster a synergistic environment for quantum and classical computing research. This paper outlines plans to unlock new computational possibilities, driving forward scientific inquiry and innovation in a wide array of research domains.

75 CONDENSED MATTER PHYSICS, SUPERCONDUCTIVITY AND↗

Generalized Nanosatellite Avionics Testbed Lab

The Generalized Nanosatellite Avionics Testbed (G-NAT) lab at NASA Ames Research Center provides a flexible, easily accessible platform for developing hardware and software for advanced small spacecraft. A collaboration between the Mission Design Division and the Intelligent Systems Division, the objective of the lab is to provide testing data and general test protocols for advanced sensors, actuators, and processors for CubeSat-class spacecraft. By developing test schemes for advanced components outside of the standard mission lifecycle, the lab is able to help reduce the risk carried by advanced nanosatellite or CubeSat missions. Such missions are often allocated very little time for testing, and too often the test facilities must be custom-built for the needs of the mission at hand. The G-NAT lab helps to eliminate these problems by providing an existing suite of testbeds that combines easily accessible, commercial-offthe- shelf (COTS) processors with a collection of existing sensors and actuators.

Testing data and general test protocols↗

SCOS 2: An object oriented software development approach

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

Symonds, Martin↗

Assuring NASA's Safety and Mission Critical Software

What is IV&V? Independent Verification and Validation (IV&V) is an objective examination of safety and mission critical software processes and products. Independence: 3 Key parameters: Technical Independence; Managerial Independence; Financial Independence. NASA IV&V perspectives: Will the system's software: Do what it is supposed to do?; Not do what it is not supposed to do?; Respond as expected under adverse conditions?. Systems Engineering: Determines if the right system has been built and that it has been built correctly. IV&V Technical Approaches: Aligned with IEEE 1012; Captured in a Catalog of Methods; Spans the full project lifecycle. IV&V Assurance Strategy: The IV&V Project's strategy for providing mission assurance; Assurance Strategy is driven by the specific needs of an individual project; Implemented via an Assurance Design; Communicated via Assurance Statements.

Validation↗