Search NASA⌕ Search

SEARCH · Search NASA

Results for “launch software”

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 127 records · Page 7

Spaceport Command and Control System: Network Engineering

The Spaceport Command and Control System (SCCS) project's goal is to facilitate the checkout and launch of NASA's next generation SLS vehicle in order to enable human exploration through deep space. SCCS is made up of complex software that will control and monitor the Space Launch System rocket and Orion spacecraft. Once it is fully developed, SCCS will be a large improvement to previous software since it takes advantage of modern computers and information making it faster and more reliable than the software used previously on the Shuttle program. The software will be tailored to the specific needs of the Space Launch System (SLS) and Orion spacecraft. These three projects will be brought together for the launch of Exploration Mission-1.

Mackh, Katherine↗

The Psyche Gamma-Ray and Neutron Spectrometer

A Gamma-Ray and Neutron Spectrometer (GRNS) instrument has been developed as part of the science payload for NASA’s Discovery Program Psyche mission to the M-class asteroid (16) Psyche. The GRNS instrument is designed to measure the elemental composition of Psyche with the goal to understand the origin of this mysterious, potentially metal-rich planetary body. The GRNS will measure the near-surface abundances for the elements Ni, Fe, Si, K, S, Al, and Ca, as well as the spatial distribution of Psyche’s metal-to-silicate fraction (or metal fraction). These measurements address three of the five Psyche mission science objectives: determine if Psyche is a core; determine whether small metal bodies incorporate light elements into the metal phase; and determine whether Psyche was formed under reducing conditions. The Gamma-Ray Spectrometer (GRS) uses a cryocooled, high-purity Ge (HPGe) sensor to detect cosmic-ray generated gamma rays in the 60 to 9000-keV energy range. The HPGe sensor is surrounded by a borated plastic anticoincidence shield that provides three functions: active background rejection from charged particle interactions in the HPGe sensor; fast neutron measurements; and direct measurements of the incident galactic cosmic ray flux. The Neutron Spectrometer (NS) uses three 3 He gas proportional sensors, each with different material wraps to measure thermal (<0.4 eV), low-energy epithermal (0.4 eV to 1 keV), and high-energy epithermal (up to 100 keV) neutrons. This paper provides an overview of the Psyche GRNS, including: its science and measurement objectives; the design of the instrument hardware, software, and operation; pre-launch performance measurements and its initial performance in space; and an overview of its data products and expected operation for different Psyche mission phases.

Engineering - Instrumentation related to nuclear s↗

NASA X-34 Technology in Motion

The X-34 technology development program is a joint industry/government project to develop, test, and operate a small, fully-reusable hypersonic flight vehicle. The objective is to demonstrate key technologies and operating concepts applicable to future reusable launch vehicles. Integrated in the vehicle are various systems to assure successful completion of mission objectives, including the Main Propulsion System (MPS). NASA-Marshall Space Flight Center (MSFC) is responsible for developing the X-34's MPS including the design and complete build package for the propulsion system components. The X-34 will be powered by the Fastrac Engine, which is currently in design and development at NASA-MSFC. Fastrac is a single-stage main engine, which burns a mixture of liquid oxygen (LOX) and kerosene(RP-1). The interface between the MPS and Fastrac engine are critical for proper system operation and technologies applicable to future reusable launch vehicles. Deneb's IGRIP software package with the Dynamic analysis option provided a key tool for conducting studies critical to this interface as well as a mechanism to drive the design of the LOX and RP-1 feedlines. Kinematic models were created for the Fastrac Engine and the feedlines for various design concepts. Based on the kinematic simulation within Envision, design and joint limits were verified and system interference controlled. It was also critical to the program to evaluate the effect of dynamic loads visually, providing a verification tool for dynamic analysis and in some cases uncovering areas that had not been considered. Deneb's software put the X-34 technology in motion and has been a key factor in facilitating the strenuous design schedule.

Beech, Geoffrey↗

Function Point Analysis Depot

The Function Point Analysis (FPA) Depot is a web application originally designed by one of the NE-C3 branch's engineers, Jamie Szafran, and created specifically for the Software Development team of the Launch Control Systems (LCS) project. The application consists of evaluating the work of each developer to be able to get a real estimate of the hours that is going to be assigned to a specific task of development. The Architect Team had made design change requests for the depot to change the schema of the application's information; that information, changed in the database, needed to be changed in the graphical user interface (GUI) (written in Ruby on Rails (RoR and the web service/server side in Java to match the database changes. These changes were made by two interns from NE-C, Ricardo Muniz from NE-C3, who made all the schema changes for the GUI in RoR and Edwin Martinez, from NE-C2, who made all the changes in the Java side.

Muniz, R.↗

Dynamic Modeling and Soil Mechanics for Path Planning of the Mars Exploration Rovers

To help minimize risk of high sinkage and slippage during drives and to better understand soil properties and rover terramechanics from drive data, a multidisciplinary team was formed under the Mars Exploration Rover project to develop and utilize dynamic computer-based models for rover drives over realistic terrains. The resulting system, named ARTEMIS (Adams-based Rover Terramechanics and Mobility Interaction System), consists of the dynamic model, a library of terramechanics subroutines, and the high-resolution digital elevation maps of the Mars surface. A 200-element model of the rovers was developed and validated for drop tests before launch, using Adams dynamic modeling software. The external library was built in Fortran and called by Adams to model the wheel-soil interactions include the rut-formation effect of deformable soils, lateral and longitudinal forces, bull-dozing effects, and applied wheel torque. The paper presents the details and implementation of the system. To validate the developed system, one study case is presented from a realistic drive on Mars of the Opportunity rover. The simulation results match well from the measurement of on-board telemetry data. In its final form, ARTEMIS will be used in a predictive manner to assess terrain navigability and will become part of the overall effort in path planning and navigation for both Martian and lunar rovers.

rover↗

Developing satellite ground control software through graphical models

This paper discusses a program of investigation into software development as graphical modeling. The goal of this work is a more efficient development and maintenance process for the ground-based software that controls unmanned scientific satellites launched by NASA. The main hypothesis of the program is that modeling of the spacecraft and its subsystems, and reasoning about such models, can--and should--form the key activities of software development; by using such models as inputs, the generation of code to perform various functions (such as simulation and diagnostics of spacecraft components) can be automated. Moreover, we contend that automation can provide significant support for reasoning about the software system at the diagram level.

Bailin, Sidney↗

Software and Human-Machine Interface Development for Environmental Controls Subsystem Support

The Space Launch System (SLS) is the next premier launch vehicle for NASA. It is the next stage of manned space exploration from American soil, and will be the platform in which we push further beyond Earth orbit. In preparation of the SLS maiden voyage on Exploration Mission 1 (EM-1), the existing ground support architecture at Kennedy Space Center required significant overhaul and updating. A comprehensive upgrade of controls systems was necessary, including programmable logic controller software, as well as Launch Control Center (LCC) firing room and local launch pad displays for technician use. Environmental control acts as an integral component in these systems, being the foremost system for conditioning the pad and extremely sensitive launch vehicle until T-0. The Environmental Controls Subsystem (ECS) required testing and modification to meet the requirements of the designed system, as well as the human factors requirements of NASA software for Validation and Verification (V&V). This term saw significant strides in the progress and functionality of the human-machine interfaces used at the launch pad, and improved integration with the controller code.

Dobson, Matthew↗

Leadership Development Program Final Project

TOSC is NASA's prime contractor tasked to successfully assemble, test, and launch the EM1 spacecraft. TOSC success is highly dependent on design products from the other NASA Programs manufacturing and delivering the flight hardware; Space Launch System(SLS) and Multi-Purpose Crew Vehicle(MPCV). Design products directly feed into TOSC's: Procedures, Personnel training, Hardware assembly, Software development, Integrated vehicle test and checkout, Launch. TOSC senior management recognized a significant schedule risk as these products are still being developed by the other two (2) programs; SVE and ACE positions were created.

Design products required for Engineering↗

Space station software reliability analysis based on failures observed during testing at the multisystem integration facility

Quality of software not only is vital to the successful operation of the space station, it is also an important factor in establishing testing requirements, time needed for software verification and integration as well as launching schedules for the space station. Defense of management decisions can be greatly strengthened by combining engineering judgments with statistical analysis. Unlike hardware, software has the characteristics of no wearout and costly redundancies, thus making traditional statistical analysis not suitable in evaluating reliability of software. A statistical model was developed to provide a representation of the number as well as types of failures occur during software testing and verification. From this model, quantitative measure of software reliability based on failure history during testing are derived. Criteria to terminate testing based on reliability objectives and methods to estimate the expected number of fixings required are also presented.

Tamayo, Tak Chai↗

Alternating Between Software Models and Real Hardware in the System Integration Lab for theIncremental Development of the Space Launch System Program Avionics

The MSFC System Integration Lab (SIL) supports avionics development of NASA’s Space Launch System—a new U.S. heavy-lift launch vehicle for NASA’s next generation of human space exploration beyond low-Earth orbit. The SIL facility allows for the incremental development of system components by either hosting real hardware in the loop and/or software models of those components. Through this functionality test teams are able to evaluate overall system performance as components are designed, built and modified. Early hardware/software integration and testing reduces risks and saves overall cost and schedule throughout a program/project life cycle. By performing early hardware/software integration, potential architecture and interface-related problems can be identified, and thus reduce associated risk as early in the design cycle as possible when problems are the least expensive to resolve while also improving the design and requirements. This presentation will illustrate the power of employing a hardware in the loop simulation system for the development of novel spacecraft avionics.

Space Launch System↗

Clouds and the Earth's Radiant Energy System (CERES) Visualization Single Satellite Footprint (SSF) Plot Generator

The first Clouds and the Earth's Radiant Energy System (CERES) instrument will be launched in 1997 to collect data on the Earth's radiation budget. The data retrieved from the satellite will be processed through twelve subsystems. The Single Satellite Footprint (SSF) plot generator software was written to assist scientists in the early stages of CERES data analysis, producing two-dimensional plots of the footprint radiation and cloud data generated by one of the subsystems. Until the satellite is launched, however, software developers need verification tools to check their code. This plot generator will aid programmers by geolocating algorithm result on a global map.

Barsi, Julia A.↗

Ground Processing Affordability for Space Vehicles

Launch vehicles and most of their payloads spend the majority of their time on the ground. The cost of ground operations is very high. So, why so often is so little attention given to ground processing during development? The current global space industry and economic environment are driving more need for efficiencies to save time and money. Affordability and sustainability are more important now than ever. We can not continue to treat space vehicles as mere science projects. More RLV's (Reusable Launch Vehicles) are being developed for the gains of reusability which are not available for ELV's (Expendable Launch Vehicles). More human-rated vehicles are being developed, with the retirement of the Space Shuttles, and for a new global space race, yet these cost more than the many unmanned vehicles of today. We can learn many lessons on affordability from RLV's. DFO (Design for Operations) considers ground operations during design, development, and manufacturing-before the first flight. This is often minimized for space vehicles, but is very important. Vehicles are designed for launch and mission operations. You will not be able to do it again if it is too slow or costly to get there. Many times, technology changes faster than space products such that what is launched includes outdated features, thus reducing competitiveness. Ground operations must be considered for the full product Lifecycle, from concept to retirement. Once manufactured, launch vehicles along with their payloads and launch systems require a long path of processing before launch. Initial assembly and testing always discover problems to address. A solid integration program is essential to minimize these impacts, as was seen in the Constellation Ares I-X test rocket. For RLV's, landing/recovery and post-flight turnaround activities are performed. Multi-use vehicles require reconfiguration. MRO (Maintenance, Repair, and Overhaul) must be well-planned--- even for the unplanned problems. Defect limits and standard repairs need to be in-place as well as easily added. Many routine inspections and maintenance can be like an aircraft overhaul. Modifications and technology upgrades should be expected. Another factor affecting ground operations efficiency is trending. It is essential for RLV's, and also useful for ELV's which fly the same or similar models again. Good data analysis of technical and processing performance will determine fixes and improvements needed for safety, design, and future processing. Collecting such data on new or low-frequency vehicles is a challenge. Lessons can be learned from the Space Shuttle, or even the Concorde aircraft. For all of the above topics, efficient business systems must be established for comprehensive program management and good throughput. Drawings, specifications, and manuals for an entire launch vehicle are often in different formats from multiple vendors, plus they have proprietary constraints. Nonetheless, the integration team must ensure that all data needed is compatible and visible to each appropriate team member. Ground processing systems for scheduling, tracking, problem resolution, etc. must be well laid-out. The balance between COTS (commercial off the shelf) and custom software is difficult. Multiple customers, vendors, launch sites, and landing sites add to the complexity of efficient IT (Information Technology) tools.

Ingalls, John↗

NASA Space Launch System Completes Green Run Testing, Begins Assembly

NASA’s Space Launch System (SLS) Program is poised in 2021 to shift its focus to the launch site with the completion of its last major integrated hardware and software test. SLS is NASA’s evolvable super heavy-lift launch vehicle for deep space exploration. Using proven propulsion technologies, SLS will be the most powerful launch vehicle in the world. That capability translates not only into more mass and volume to destinations but also simplified payload design and mission operations and greater opportunity for mission success. These capabilities will be important for the Artemis program, NASA’s plan to return humans to the Moon to stay in a sustainable way in order to develop and test technologies and operations needed for human missions to Mars and other destinations. SLS will anchor the transportation leg of an innovative, sustainable program of lunar exploration with commercial and international partners as the first step of human exploration of deep space. While all major hardware and software efforts made significant progress in 2020 and 2021, the most visible was the Green Run test series of the Artemis I core stage conducted at NASA’s Stennis Space Center (SSC) on the B-2 test stand. The series validated core stage design, performance, workmanship, and readiness for shipment to NASA Kennedy Space Center (KSC) for final processing, integration and launch. The core stage provides the backbone for SLS’ main propulsion system, consisting of two five-segment solid rocket boosters and four RS-25 liquid hydrogen (LH2)/liquid oxygen (LOX) engines. SLS also includes an Interim Cryogenic Propulsion Stage (ICPS) that will insert the Orion crew spacecraft into a lunar trajectory.

John Honeycutt↗

Titan/Centaur D-1T TC-2, Helios A flight data report

Background data of spacecraft launching and flight are presented. A system analysis of the space vehicles is included, specifically on: (1) electronic equipment, (2) hydraulic equipment, (3) telemetry, (4) propulsion systems, (5) software (computers), and (6) guidance. Spacecraft and launch vehicle configurations are shown and described.

Source record↗

Spaceport Command and Control System Software Development

The control system for the Space Launch System (SLS) and Orion capsule contains a multitude of displays for use in displaying information like vehicle health, sensor information, life support, etc. Currently users in the Launch Control Center (LCC) are using a list-based selection Graphical User Interface (GUI) to open various displays. However the display names are not intuitive as to what the display looks like nor what data is presented in a display. My project involves adding additional functionality to the current display selection GUI utilizing thumbnail images of each display for easy browsing. This new GUI allows users to find their desired display much faster without needing to memorize the layout of every display based only on the display's name.

Chapa, Nicholas↗

ExaWorks software development kit: a robust and scalable collection of interoperable workflows technologies

Scientific discovery increasingly requires executing heterogeneous scientific workflows on high-performance computing (HPC) platforms. Heterogeneous workflows contain different types of tasks (e.g., simulation, analysis, and learning) that need to be mapped, scheduled, and launched on different computing. That requires a software stack that enables users to code their workflows and automate resource management and workflow execution. Currently, there are many workflow technologies with diverse levels of robustness and capabilities, and users face difficult choices of software that can effectively and efficiently support their use cases on HPC machines, especially when considering the latest exascale platforms. We contributed to addressing this issue by developing the ExaWorks Software Development Kit (SDK). The SDK is a curated collection of workflow technologies engineered following current best practices and specifically designed to work on HPC platforms. We present our experience with (1) curating those technologies, (2) integrating them to provide users with new capabilities, (3) developing a continuous integration platform to test the SDK on DOE HPC platforms, (4) designing a dashboard to publish the results of those tests, and (5) devising an innovative documentation platform to help users to use those technologies. Our experience details the requirements and the best practices needed to curate workflow technologies, and it also serves as a blueprint for the capabilities and services that DOE will have to offer to support a variety of scientific heterogeneous workflows on the newly available exascale HPC platforms.

97 MATHEMATICS AND COMPUTING↗