Results for “launch software” — Page 19

NASA NTRS2008

Constellation Training Facility Support

The National Aeronautics and Space Administration is developing the next set of vehicles that will take men back to the moon under the Constellation Program. The Constellation Training Facility (CxTF) is a project in development that will be used to train astronauts, instructors, and flight controllers on the operation of Constellation Program vehicles. It will also be used for procedure verification and validation of flight software and console tools. The CxTF will have simulations for the Crew Exploration Vehicle (CEV), Crew Module (CM), CEV Service Module (SM), Launch Abort System (LAS), Spacecraft Adapter (SA), Crew Launch Vehicle (CLV), Pressurized Cargo Variant CM, Pressurized Cargo Variant SM, Cargo Launch Vehicle, Earth Departure Stage (EDS), and the Lunar Surface Access Module (LSAM). The Facility will consist of part-task and full-task trainers, each with a specific set of mission training capabilities. Part task trainers will be used for focused training on a single vehicle system or set of related systems. Full task trainers will be used for training on complete vehicles and all of its subsystems. Support was provided in both software development and project planning areas of the CxTF project. Simulation software was developed for the hydraulic system of the Thrust Vector Control (TVC) of the ARES I launch vehicle. The TVC system is in charge of the actuation of the nozzle gimbals for navigation control of the upper stage of the ARES I rocket. Also, software was developed using C standards to send and receive data to and from hand controllers to be used in CxTF cockpit simulations. The hand controllers provided movement in all six rotational and translational axes. Under Project Planning & Control, support was provided to the development and maintenance of integrated schedules for both the Constellation Training Facility and Missions Operations Facilities Division. These schedules maintain communication between projects in different levels. The CxTF support provided is one that requires continuous maintenance since the project is still on initial development phases.

Flores, Jose M.↗

NASA NTRS2008

Ares-I Bending Filter Design using a Constrained Optimization Approach

The Ares-I launch vehicle represents a challenging flex-body structural environment for control system design. Software filtering of the inertial sensor output is required to ensure adequate stable response to guidance commands while minimizing trajectory deviations. This paper presents a design methodology employing numerical optimization to develop the Ares-I bending filters. The design objectives include attitude tracking accuracy and robust stability with respect to rigid body dynamics, propellant slosh, and flex. Under the assumption that the Ares-I time-varying dynamics and control system can be frozen over a short period of time, the bending filters are designed to stabilize all the selected frozen-time launch control systems in the presence of parameter uncertainty. To ensure adequate response to guidance command, step response specifications are introduced as constraints in the optimization problem. Imposing these constrains minimizes performance degradation caused by the addition of the bending filters. The first stage bending filter design achieves stability by adding lag to the first structural frequency to phase stabilize the first flex mode while gain stabilizing the higher modes. The upper stage bending filter design gain stabilizes all the flex bending modes. The bending filter designs provided here have been demonstrated to provide stable first and second stage control systems in both Draper Ares Stability Analysis Tool (ASAT) and the MSFC MAVERIC 6DOF nonlinear time domain simulation.

Hall, Charles↗

NASA NTRS2018

Rapid Model Import Tool (RMIT)

Our project is about developing a tool to implement conversion of 3D Computer Aided Design (CAD) models produced with software such as Delmia, 3DS Max, or Maya, into a size and format compatible with the Unity 3D environment. RMIT will be used to aid KSC engineering personnel in the design, development, testing, operations, and training on spacecraft, launch vehicles, facilities, and ground support equipment. For our project, we are using Blender, a free/open-source 3D graphics software, with the goal of developing, testing, and deploying a 3D CAD model converter tool. I worked on using Blender to import 3D CAD models exported from CATIA software into Collada file format. The Collada file format has file extension DAE. Importing the Collada DAE file as is into Blender, generates dots and dashes. In 3DS Max, there is an existing OpenCollada plugin and with that plugin, 3DS Max can import the DAE file successfully. But, Blender does not seem to have an OpenCollada plugin, so I worked on writing a new OpenCollada plugin for Blender. Since 3DS Max was able to display the image, I looked into comparing differences between the original DAE file and the DAE file exported from 3DS Max using the OpenCollada plugin. As Collada documents describing digital assets are XML files with file extension DAE, Collada files contains XML tags, making them easily modifiable. After some research, it appears that Blender does not like primitive 2D tags like tristrips and trifans. Changing those tags to polygons slightly improved the image, but the pieces were exploded. I found after further research comparing differences between the original file and the file exported from 3DS Max that the values inside the translate tags in the original file are scaled down by a factor of 25.4 in the exported file from 3DS Max, representing the millimeters to inches conversion (1 inch = 25.4 millimeters). After scaling down values inside all of the translate tags by 25.4, the exploded pieces stuck back in, but the image needed further improvement. I have been able to create a new plugin in Blender that takes the original DAE file, replaces the primitive 2D tags tristrips and trifans with polygons, scales down the values inside the translate tags by a factor of 25.4, and saves the changes into a temporary DAE file. After the temporary DAE file is imported into Blender, the temp file is then deleted, keeping the original DAE file intact. Starting with a DAE file that is exported using the NASA Enterprise Visualization Application (NEVA), a Collada exporter, from CATIA gives better results. NEVA is a Design Visualization product that is used for exporting 3D models from CATIA. With NEVA, the up axis is defined in the top-level node if navigation gravity is enabled. With that file, just replacing the primitive tags tristrips and trifans with polygons in yields a much improved image in Blender. As we identify more differences between the original DAE file and the DAE file exported from 3DS Max, this plugin can be improved further. Our goal is to have a model that is formatted and sized for import into Unity, and we are trying out different 3D programs to see which will work best.

Ayyangar, Arjun↗

NASA NTRS2015

NASA Affordable Vehicle Avionics (AVA): Common Modular Avionics System for Nano-Launchers Offering Affordable Access to Space

Small satellites are becoming ever more capable of performing valuable missions for both government and commercial customers. However, currently these satellites can only be launched affordably as secondary payloads. This makes it difficult for the small satellite mission to launch when needed, to the desired orbit, and with acceptable risk. NASA Ames Research Center has developed and tested a prototype low-cost avionics package for space launch vehicles that provides complete GNC functionality in a package smaller than a tissue box with a mass less than 0.84 kg. AVA takes advantage of commercially available, low-cost, mass-produced, miniaturized sensors, filtering their more noisy inertial data with realtime GPS data. The goal of the Advanced Vehicle Avionics project is to produce and flight-verify a common suite of avionics and software that deliver affordable, capable GNC and telemetry avionics with application to multiple nano-launch vehicles at 1 the cost of current state-of-the-art avionics.

Guidance Navigation and Control↗

NASA NTRS2013

A Software Upgrade of the NASA Aeroheating Code "MINIVER"

Computational Fluid Dynamics (CFD) is a powerful and versatile tool simulating fluid and thermal environments of launch and re-entry vehicles alike. Where it excels in power and accuracy, however, it lacks in speed. An alternative tool for this purpose is known as MINIVER, an aeroheating code widely used by NASA and within the aerospace industry. Capable of providing swift, reasonably accurate approximations of the fluid and thermal environment of launch vehicles, MINIVER is used where time is of the essence and accuracy need not be exact. However, MINIVER is an old, aging tool: running on a user-unfriendly, legacy command-line interface, it is difficult for it to keep pace with more modem software tools. Florida Institute of Technology was tasked with the construction of a new Graphical User Interface (GUI) that implemented the legacy version's capabilities and enhanced them with new tools and utilities. This thesis provides background to the legacy version of the program, the progression and final version of a modem user interface, and benchmarks to demonstrate its usefulness.

Louderback, Pierce Mathew↗

NASA NTRS2001

Chandra Space Flight Software: Using Software to Autonomously Operation the Largest and Most Sensitive X-Ray Telescope in the World

Chandra is the world's largest and most sensitive X-ray telescope. The Chandra X-ray Observatory is the third in NASA's family of "Great Observatories." The Chandra X-ray Observatory, launched by Space Shuttle Columbia on July 23, 1999, is NASA's newest Great Observatory. The Chandra space flight software is the operational software, which controls and directs the Chandra X-ray Observatory. The Chandra flight software has executed faultlessly for over 13,000 hours on-orbit. The Chandra flight software directly controls the Pointing, Aspect Determination, Electrical Power Subsystem, Propulsion system, and the Command, Communications, and Data Management subsystems. The software controls the spacecraft operations during all phases of the mission. The software also performs thermal control of the telescope to maintain pointing accuracy and monitors radiation levels throughout the orbit so that the Science Instruments can be safed if radiation thresholds are exceeded. The efficient operation of Chandra flight software has enabled the gathering of crucial science data. The Chandra flight software fault protection is the key to early detection and prevention of science instrument or spacecraft damage in an operating platform/environment, which is completely unforgiving. Permanently open Sun Shade Door and ACIS focal plane radiator sensitivity exposes science instruments and mirrors to damage for pointing anomalies causing an attitude excursion. The Chandra flight software must prevent these attitude excursions from occurring for ANY failure. Another example is that the power system has an unregulated bus, which imposes severe operating requirements on Chandra flight software to control array pointing and battery connection/disconnect using a unique algorithmic and logic approach. The Chandra flight software has enabled a truly autonomous vehicle with greater than 99% of all mission data collected as planned. Less than 15% of spacecraft operations are conducted in view (1 hour out of 8) leading to very extended periods without ground contact. The Chandra flight software implements the flexible mission plan during this out of view period, manages the solid state recorder capacity, controls all pointing and maneuvers, provides fault detection for all satellite subsystems, and initiates communications with the ground at the appropriate time. This paper will describe the software architecture features, key design elements and software testing techniques that have facilitated Chandra's success.

Crumbley, Tim↗

NASA NTRS1988

An experiment in software reliability: Additional analyses using data from automated replications

A study undertaken to collect software error data of laboratory quality for use in the development of credible methods for predicting the reliability of software used in life-critical applications is summarized. The software error data reported were acquired through automated repetitive run testing of three independent implementations of a launch interceptor condition module of a radar tracking problem. The results are based on 100 test applications to accumulate a sufficient sample size for error rate estimation. The data collected is used to confirm the results of two Boeing studies reported in NASA-CR-165836 Software Reliability: Repetitive Run Experimentation and Modeling, and NASA-CR-172378 Software Reliability: Additional Investigations into Modeling With Replicated Experiments, respectively. That is, the results confirm the log-linear pattern of software error rates and reject the hypothesis of equal error rates per individual fault. This rejection casts doubt on the assumption that the program's failure rate is a constant multiple of the number of residual bugs; an assumption which underlies some of the current models of software reliability. data raises new questions concerning the phenomenon of interacting faults.

Dunham, Janet R.↗

NASA NTRS2011

The Use of Modeling for Flight Software Engineering on SMAP

The Soil Moisture Active Passive (SMAP) mission proposes to deploy an Earth-orbiting satellite with the goal of obtaining global maps of soil moisture content at regular intervals. Launch is currently planned in 2014. The spacecraft bus would be built at the Jet Propulsion Laboratory (JPL), incorporating both new avionics as well as hardware and software heritage from other JPL projects. [4] provides a comprehensive overview of the proposed mission

Software architecture↗

NASA NTRS2017

Spaceport Command and Control System Software Development

The Spaceport Command and Control System (SCCS) is the National Aeronautics and Space Administration's (NASA) launch control system for the Orion capsule and Space Launch System, the next generation manned rocket currently in development. This large system requires a large amount of intensive testing that will properly measure the capabilities of the system. Automating the test procedures would save the project money from human labor costs, as well as making the testing process more efficient. Therefore, the Exploration Systems Division (formerly the Electrical Engineering Division) at Kennedy Space Center (KSC) has recruited interns for the past two years to work alongside full-time engineers to develop these automated tests, as well as innovate upon the current automation process.

Glasser, Abraham↗

NASA NTRS1993

Future space transportation system architecture avionics requirements

NASA began a multi-center study in January 1993 to examine options for providing the most cost effective space transportation system in the future. The key advanced avionics requirements for these vehicle concepts are envisioned to provide significantly improved operational efficiency and effectiveness. It is very desirable to have adaptive guidance, navigation, and control approaches that will allow launch and return in almost any weather condition. The vehicles must be able to accommodate atmospheric density variations and winds without software changes. The flight operations must become much more autonomous in all flight regimes like an aircraft, and preflight checkout should make use of the onboard systems. When the vehicle returns to the launch site, subsystem health must be known and maintenance tasks scheduled accordingly. Ground testing of most subsystems must be eliminated. Also, the health monitoring system must be designed to enhance the ability to abort the mission significantly and save the crew and the vehicle. The displays and controls must be much less complex than current systems and must significantly reduce pilot work load. It is important to have low power, light weight displays and controls. Rendezvous and docking and all flight phases must have autopilot capability to reduce pilot work load for routine operations and in abort situations. The vehicles must have the demonstrated ability to return to the launch site. Abort from all mission phases can put additional demands on the communications system.

Stone, Howard↗

NASA NTRSDate not supplied

Automated Software for Manned Spacecraft - Bridging the Gap from Sci Fi to Reality

With a voice command or a few taps on the console, the spacecraft pivots on a dime at high velocity and gently docks to an orbiting space platform. This is the image most people have of the complex software computations and integrated hardware performance necessary for a spacecraft to successfully perform an automated launch, rendezvous, and docking. Today’s reality is that while computer operations are advancing rapidly, science fiction over-simplifies and over-sells current capabilities. This paper discusses the integration of spacecraft computer automation into the operation of one of the United States’ new Commercial Crew vehicles - the Boeing CST-100 Starliner. Lessons learned by the Boeing Mission Operations team, a private-public partnership with NASA, from conceptual design through real-time operation of the first test flight will be discussed. Focus will center on how operations has learned to use the automated software to their advantage while also knowing how to adjust the automation in response to spacecraft or mission anomalies. One goal of advanced spacecraft automation is the ability to reduce both the crew workload and the ground control footprint while at the same time increasing spacecraft and mission flexibility. Historically, crewed spacecraft required a large number of operators on the ground to use a plethora of tools to compute nominal and contingency mission trajectories. Moving those sophisticated software tools to being onboard the vehicle can reduce the need for such complex ground support. Given that today’s spacecraft software is not yet as capable or as flexible in all circumstances as the computers depicted in movies, there is usually a trade-off between software automation cost and the flexibility of that software resulting in a trade-off between what is performed on the spacecraft and what is left to onboard crew or ground control. For missions that go beyond the Moon, software that autonomously controls nearly every aspect of a crewed mission will become a necessity given the long time delays between the spacecraft and Earth’s ground control teams. The lessons learned by Boeing and its Mission Operations team, through the design and implementation of Starliner’s hardware and software automation, will be able to inform future public and private spacecraft design. As the technologies and capabilities evolve, incorporating lessons learned in successful low Earth orbit commercial crew vehicle missions, spacecraft designs will continue to improve and be able to better enable safe execution of human missions to the Moon and beyond.

Robert C Dempsey↗

NASA NTRSDate not supplied

Automated Software for Manned Spacecraft - Bridging the Gap from Sci Fi to Reality

With a voice command or a few taps on the console, the spacecraft pivots on a dime at high velocity and gently docks to an orbiting space platform. This is the image most people have of the complex software computations and integrated hardware performance necessary for a spacecraft to successfully perform an automated launch, rendezvous, and docking. Today’s reality is that while computer operations are advancing rapidly, science fiction over-simplifies and over-sells current capabilities. This paper discusses the integration of spacecraft computer automation into the operation of one of the United States’ new Commercial Crew vehicles - the Boeing CST-100 Starliner. Lessons learned by the Boeing Mission Operations team, a private-public partnership with NASA, from conceptual design through real-time operation of the first test flight will be discussed. Focus will center on how operations has learned to use the automated software to their advantage while also knowing how to adjust the automation in response to spacecraft or mission anomalies. One goal of advanced spacecraft automation is the ability to reduce both the crew workload and the ground control footprint while at the same time increasing spacecraft and mission flexibility. Historically, crewed spacecraft required a large number of operators on the ground to use a plethora of tools to compute nominal and contingency mission trajectories. Moving those sophisticated software tools to being onboard the vehicle can reduce the need for such complex ground support. Given that today’s spacecraft software is not yet as capable or as flexible in all circumstances as the computers depicted in movies, there is usually a trade-off between software automation cost and the flexibility of that software resulting in a trade-off between what is performed on the spacecraft and what is left to onboard crew or ground control. For missions that go beyond the Moon, software that autonomously controls nearly every aspect of a crewed mission will become a necessity given the long time delays between the spacecraft and Earth’s ground control teams. The lessons learned by Boeing and its Mission Operations team, through the design and implementation of Starliner’s hardware and software automation, will be able to inform future public and private spacecraft design. As the technologies and capabilities evolve, incorporating lessons learned in successful low Earth orbit commercial crew vehicle missions, spacecraft designs will continue to improve and be able to better enable safe execution of human missions to the Moon and beyond.

Robert C. Dempsey↗

NASA NTRSDate not supplied

Automated Software for Crewed Spacecraft - Bridging the Gap from Sci Fi to Reality

With a voice command or a few taps on the console, the spacecraft pivots on a dime at high velocity and gently docks to an orbiting space platform. This is the image most people have of the complex software computations and integrated hardware performance necessary for a spacecraft to successfully perform an automated launch, rendezvous, and docking. Today’s reality is that while computer operations are advancing rapidly, science fiction over-simplifies and over-sells current capabilities. This paper discusses the integration of spacecraft computer automation into the operation of one of the United States’ new Commercial Crew vehicles - the Boeing CST-100 Starliner. Lessons learned by the Boeing Mission Operations team, a private-public partnership with NASA, from conceptual design through real-time operation of the first test flight will be discussed. Focus will center on how operations has learned to use the automated software to their advantage while also knowing how to adjust the automation in response to spacecraft or mission anomalies. One goal of advanced spacecraft automation is the ability to reduce both the crew workload and the ground control footprint while at the same time increasing spacecraft and mission flexibility. Historically, crewed spacecraft required a large number of operators on the ground to use a plethora of tools to compute nominal and contingency mission trajectories. Moving those sophisticated software tools to being onboard the vehicle can reduce the need for such complex ground support. Given that today’s spacecraft software is not yet as capable or as flexible in all circumstances as the computers depicted in movies, there is usually a trade-off between software automation cost and the flexibility of that software resulting in a trade-off between what is performed on the spacecraft and what is left to onboard crew or ground control. For missions that go beyond the Moon, software that autonomously controls nearly every aspect of a crewed mission will become a necessity given the long time delays between the spacecraft and Earth’s ground control teams. The lessons learned by Boeing and its Mission Operations team, through the design and implementation of Starliner’s hardware and software automation, will be able to inform future public and private spacecraft design. As the technologies and capabilities evolve, incorporating lessons learned in successful low Earth orbit commercial crew vehicle missions, spacecraft designs will continue to improve and be able to better enable safe execution of human missions to the Moon and beyond.

Robert C Dempsey↗

NASA NTRS1979

Space Shuttle Orbiter - Countdown

The status of Orbiter launch planning is reviewed, with consideration given to major structure elements, subsystem and component development, readiness for launch, and follow-on Orbiters. It is noted that timelines in the completion of each increment of development of the first Orbital Flight Vehicle become increasingly crucial as the scheduled launch date approaches. Concurrent with the testing and finalization of this vehicle's software and hardware construction are the preliminary developmental stages of future Shuttle Orbiters.

Cohen, A.↗

NASA NTRS1981

Spacecraft attitude calibration/verification baseline study

A baseline study for a generalized spacecraft attitude calibration/verification system is presented. It can be used to define software specifications for three major functions required by a mission: the pre-launch parameter observability and data collection strategy study; the in-flight sensor calibration; and the post-calibration attitude accuracy verification. Analytical considerations are given for both single-axis and three-axis spacecrafts. The three-axis attitudes considered include the inertial-pointing attitudes, the reference-pointing attitudes, and attitudes undergoing specific maneuvers. The attitude sensors and hardware considered include the Earth horizon sensors, the plane-field Sun sensors, the coarse and fine two-axis digital Sun sensors, the three-axis magnetometers, the fixed-head star trackers, and the inertial reference gyros.

Chen, L. C.↗

NASA NTRS1986

Simulation of PCM Data

Program for communications and control computer simulates pulse-codemodulated data. Software for simulation pulse-code-modulated (PCM) data from Space Shuttle during launch preparations developed for use with checkout, control, and monitor subsystem (CCMS). Facilitates testing of CCMS with data expected from main engines, external fuel tanks, operational instrumentation, general-purpose computer, backup flight system, and payload. Simulator program executes in standard CCMS hardware, requiring no new hardware.

Bernstrom, G. G.↗

NASA NTRS1998

The Role of Computational Fluid Dynamics at Marshall Space Flight Center

The Marshall Space Flight Center (MSFC) is the Center of Excellence for Space Propulsion Technology within NASA. One of MSFC's goals is to lower the cost of access to space. MSFC's Fluid Dynamics Division, a part of the Structures and Dynamics Lab, assists in accomplishing this goal. This division is divided into two branches: experimental and analytical, whose work is complimentary and integrated. In the analysis branch, the emphasis is to apply, rather than develop computational fluid dynamics (CFD), to reduce the cost of design and development of: (1) pump and turbine feedlines and feed manifolds; (2) all primary and secondary flow paths in pumps; (3) all primary and secondary flow paths in turbines; (4) combustion chambers; (5) rocket engine nozzles and plumes; and (6) launch vehicles ascent. The broad range of applications imposes unique constraints on the software. The use of CFD in evaluating rocket engine hardware, specifically, is of value due to several reasons: (1) Rocket engine hardware is extremely expensive to build and test; (2) high engineering and development cost is due to limited production; (3) the cost of one engine test is greater than the average yearly hardware and software cost; (4) CFD represents a relatively small investment relative to the impact it has on the engine development; and (5) computing costs are continuously decreasing. In terms of accuracy the predictable error is more useful than the inconsistent accuracy. The achievable accuracy varies from application to application. The lack of accuracy is often caused by improper analyses: such as improperly applied or located boundary conditions, or attempting steady analysis of unsteady flows. This report is in viewgraph format.

Garcia, Roberto↗

NASA NTRS2000

IVHM for the 3rd Generation RLV Program: Technology Development

The objective behind the Integrated Vehicle Health Management (IVHM) project is to develop and integrate the technologies which can provide a continuous, intelligent, and adaptive health state of a vehicle and use this information to improve safety and reduce costs of operations. Technological areas discussed include: developing, validating, and transfering next generation IVHM technologies to near term industry and government reusable launch systems; focus NASA on the next generation and highly advanced sensor and software technologies; and validating IVHM systems engineering design process for future programs.

Kahle, Bill↗