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 37 records · Page 2
All sourcesNASA NTRSDOE OSTI
NASA NTRS2006

Crew Launch Vehicle (CLV) Avionics and Software Integration Overview

On January 14, 2004, the President of the United States announced a new plan to explore space and extend a human presence across our solar system. The National Aeronautics and Space Administration (NASA) established the Exploration Systems Mission Directorate (ESMD) to develop and field a Constellation Architecture that will bring the Space Exploration vision to fruition. The Constellation Architecture includes a human-rated Crew Launch Vehicle (CLV) segment, managed by the Marshall Space Flight Center (MSFC), comprised of the First Stage (FS), Upper Stage (US), and Upper Stage Engine (USE) elements. The CLV s purpose is to provide safe and reliable crew and cargo transportation into Low Earth Orbit (LEO), as well as insertion into trans-lunar trajectories. The architecture's Spacecraft segment includes, among other elements, the Crew Exploration Vehicle (CEV), managed by the Johnson Space Flight Center (JSC), which is launched atop the CLV. MSFC is also responsible for CLV and CEV stack integration. This paper provides an overview of the Avionics and Software integration approach (which includes the Integrated System Health Management (ISHM) functions), both within the CLV, and across the CEV interface; it addresses the requirements to be met, logistics of meeting those requirements, and the roles of the various groups. The Avionics Integration and Vehicle Systems Test (ANST) Office was established at the MSFC with system engineering responsibilities for defining and developing the integrated CLV Avionics and Software system. The AIVST Office has defined two Groups, the Avionics and Software Integration Group (AVSIG), and the Integrated System Simulation and Test Integration Group (ISSTIG), and four Panels which will direct trade studies and analyses to ensure the CLV avionics and software meet CLV system and CEV interface requirements. The four panels are: 1) Avionics Integration Panel (AIP), 2) Software Integration Panel, 3) EEE Panel, and 4) Systems Simulation and Test Panel. Membership on the groups and panels includes the MSFC representatives from the requisite engineering disciplines, the First Stage, the Upper Stage, the Upper Stage Engine projects, and key personnel from other NASA centers. The four panels will take the results of trade studies and analyses and develop documentation in support of Design Analysis Cycle Reviews and ultimately the System Requirements Review.

Monell, Donald W.↗
NASA NTRS2003

Integrated Software for Analyzing Designs of Launch Vehicles

Launch Vehicle Analysis Tool (LVA) is a computer program for preliminary design structural analysis of launch vehicles. Before LVA was developed, in order to analyze the structure of a launch vehicle, it was necessary to estimate its weight, feed this estimate into a program to obtain pre-launch and flight loads, then feed these loads into structural and thermal analysis programs to obtain a second weight estimate. If the first and second weight estimates differed, it was necessary to reiterate these analyses until the solution converged. This process generally took six to twelve person-months of effort. LVA incorporates text to structural layout converter, configuration drawing, mass properties generation, pre-launch and flight loads analysis, loads output plotting, direct solution structural analysis, and thermal analysis subprograms. These subprograms are integrated in LVA so that solutions can be iterated automatically. LVA incorporates expert-system software that makes fundamental design decisions without intervention by the user. It also includes unique algorithms based on extensive research. The total integration of analysis modules drastically reduces the need for interaction with the user. A typical solution can be obtained in 30 to 60 minutes. Subsequent runs can be done in less than two minutes.

Philips, Alan D.↗
NASA NTRS2008

SDO FlatSat Facility

The goal of the Solar Dynamics Observatory (SDO) is to understand and, ideally, predict the solar variations that influence life and society. It's instruments will measure the properties of the Sun and will take hifh definition images of the Sun every few seconds, all day every day. The FlatSat is a high fidelity electrical and functional representation of the SDO spacecraft bus. It is a high fidelity test bed for Integration & Test (I & T), flight software, and flight operations. For I & T purposes FlatSat will be a driver to development and dry run electrical integration procedures, STOL test procedures, page displays, and the command and telemetry database. FlatSat will also serve as a platform for flight software acceptance and systems testing for the flight software system component including the spacecraft main processors, power supply electronics, attitude control electronic, gimbal control electrons and the S-band communications card. FlatSat will also benefit the flight operations team through post-launch flight software code and table update development and verification and verification of new and updated flight operations products. This document highlights the benefits of FlatSat; describes the building of FlatSat; provides FlatSat facility requirements, access roles and responsibilities; and, and discusses FlatSat mechanical and electrical integration and functional testing.

Amason, David L.↗
NASA NTRS2007

Imaging Sensor Flight and Test Equipment Software

The Lightning Imaging Sensor (LIS) is one of the components onboard the Tropical Rainfall Measuring Mission (TRMM) satellite, and was designed to detect and locate lightning over the tropics. The LIS flight code was developed to run on a single onboard digital signal processor, and has operated the LIS instrument since 1997 when the TRMM satellite was launched. The software provides controller functions to the LIS Real-Time Event Processor (RTEP) and onboard heaters, collects the lightning event data from the RTEP, compresses and formats the data for downlink to the satellite, collects housekeeping data and formats the data for downlink to the satellite, provides command processing and interface to the spacecraft communications and data bus, and provides watchdog functions for error detection. The Special Test Equipment (STE) software was designed to operate specific test equipment used to support the LIS hardware through development, calibration, qualification, and integration with the TRMM spacecraft. The STE software provides the capability to control instrument activation, commanding (including both data formatting and user interfacing), data collection, decompression, and display and image simulation. The LIS STE code was developed for the DOS operating system in the C programming language. Because of the many unique data formats implemented by the flight instrument, the STE software was required to comprehend the same formats, and translate them for the test operator. The hardware interfaces to the LIS instrument using both commercial and custom computer boards, requiring that the STE code integrate this variety into a working system. In addition, the requirement to provide RTEP test capability dictated the need to provide simulations of background image data with short-duration lightning transients superimposed. This led to the development of unique code used to control the location, intensity, and variation above background for simulated lightning strikes at user-selected locations.

Freestone, Kathleen↗
NASA NTRS2004

[Activities of System Studies and Simulation, Inc.]

Contents include the following: 1. Launch Vehicle Interface Work Performed: a. S3 provided to KSC the new launch inclination targets needed for the April '04 launch date. 2. Prelaunch operations work performed: a. S3 updated the staffing plan for MSFC on-console personnel\during the Final Countdown prior to launch. 3. Software Assessment Work Performed: a. S3 evaluated and recommended approval for Program Control Board (PCB) proposed change 649 for ground software changes, as well as change 650 and 650A for Stored Program Commands. 4. Education and Public Outreach Work Performed: a. S3 continues to coordinate the effort for the design and fabrication of scale models of the GP-3 for use at the launch site, education forums, and management/technical briefings. S3 also prepared a Change Request for additional funds needed for fabrication of additional scale models. S3 drafted the planned uses of these models, including the possibility of participation in the Boston, MA showings of the traveling Einstein Exhibit. 5. Program Management Support Work Performed: a. S3 prepared the input for and closed three MSFC Centerwide Action Item Tracking Systems (CAITS) actions during this period.

Source record↗
NASA NTRS2011

Mars Science Laboratory Flight Software Internal Testing

The Mars Science Laboratory (MSL) team is sending the rover, Curiosity, to Mars, and therefore is physically and technically complex. During my stay, I have assisted the MSL Flight Software (FSW) team in implementing functional test scripts to ensure that the FSW performs to the best of its abilities. There are a large number of FSW requirements that have been written up for implementation; however I have only been assigned a few sections of these requirements. There are many stages within testing; one of the early stages is FSW Internal Testing (FIT). The FIT team can accomplish this with simulation software and the MSL Test Automation Kit (MTAK). MTAK has the ability to integrate with the Software Simulation Equipment (SSE) and the Mission Processing and Control System (MPCS) software which makes it a powerful tool within the MSL FSW development process. The MSL team must ensure that the rover accomplishes all stages of the mission successfully. Due to the natural complexity of this project there is a strong emphasis on testing, as failure is not an option. The entire mission could be jeopardized if something is overlooked.

entry, descent, and landing (EDL)↗
NASA NTRS2006

Ultra reliability at NASA

Ultra reliable systems are critical to NASA particularly as consideration is being given to extended lunar missions and manned missions to Mars. NASA has formulated a program designed to improve the reliability of NASA systems. The long term goal for the NASA ultra reliability is to ultimately improve NASA systems by an order of magnitude. The approach outlined in this presentation involves the steps used in developing a strategic plan to achieve the long term objective of ultra reliability. Consideration is given to: complex systems, hardware (including aircraft, aerospace craft and launch vehicles), software, human interactions, long life missions, infrastructure development, and cross cutting technologies. Several NASA-wide workshops have been held, identifying issues for reliability improvement and providing mitigation strategies for these issues. In addition to representation from all of the NASA centers, experts from government (NASA and non-NASA), universities and industry participated. Highlights of a strategic plan, which is being developed using the results from these workshops, will be presented.

risk↗
NASA NTRS2011

ISS Operations Cost Reductions Through Automation of Real-Time Planning Tasks

In 2008 the Johnson Space Center s Mission Operations Directorate (MOD) management team challenged their organization to find ways to reduce the costs of International Space station (ISS) console operations in the Mission Control Center (MCC). Each MOD organization was asked to identify projects that would help them attain a goal of a 30% reduction in operating costs by 2012. The MOD Operations and Planning organization responded to this challenge by launching several software automation projects that would allow them to greatly improve ISS console operations and reduce staffing and operating costs. These projects to date have allowed the MOD Operations organization to remove one full time (7 x 24 x 365) ISS console position in 2010; with the plan of eliminating two full time ISS console support positions by 2012. This will account for an overall 10 EP reduction in staffing for the Operations and Planning organization. These automation projects focused on utilizing software to automate many administrative and often repetitive tasks involved with processing ISS planning and daily operations information. This information was exchanged between the ground flight control teams in Houston and around the globe, as well as with the ISS astronaut crew. These tasks ranged from managing mission plan changes from around the globe, to uploading and downloading information to and from the ISS crew, to even more complex tasks that required multiple decision points to process the data, track approvals and deliver it to the correct recipient across network and security boundaries. The software solutions leveraged several different technologies including customized web applications and implementation of industry standard web services architecture between several planning tools; as well as a engaging a previously research level technology (TRL 2-3) developed by Ames Research Center (ARC) that utilized an intelligent agent based system to manage and automate file traffic flow, archiving f data, and generating console logs. This technology called OCAMS (OCA (Orbital Communication System) Management System), is now considered TRL level 9 and is in daily use in the Mission Control Center in support of ISS operations. These solutions have not only allowed for improved efficiency on console; but since many of the previously manual data transfers are now automated, many of the human error prone steps have been removed, and the quality of the planning products has improved tremendously. This has also allowed our Planning Flight Controllers more time to focus on the abstract areas of the job, (like the complexities of planning a mission for 6 international crew members with a global planning team), instead of being burdened with the administrative tasks that took significant time each console shift to process. The resulting automation solutions have allowed the Operations and Planning organization to realize significant cost savings for the ISS program through 2020 and many of these solutions could be a viable

Hall, Timothy A.↗
NASA NTRS2011

ISS Operations Cost Reductions Through Automation of Real-Time Planning Tasks

In 2007 the Johnson Space Center s Mission Operations Directorate (MOD) management team challenged their organizations to find ways to reduce the cost of operations for supporting the International Space Station (ISS) in the Mission Control Center (MCC). Each MOD organization was asked to define and execute projects that would help them attain cost reductions by 2012. The MOD Operations Division Flight Planning Branch responded to this challenge by launching several software automation projects that would allow them to greatly improve console operations and reduce ISS console staffing and intern reduce operating costs. These tasks ranged from improving the management and integration mission plan changes, to automating the uploading and downloading of information to and from the ISS and the associated ground complex tasks that required multiple decision points. The software solutions leveraged several different technologies including customized web applications and implementation of industry standard web services architecture; as well as engaging a previously TRL 4-5 technology developed by Ames Research Center (ARC) that utilized an intelligent agent-based system to manage and automate file traffic flow, archive data, and generate console logs. These projects to date have allowed the MOD Operations organization to remove one full time (7 x 24 x 365) ISS console position in 2010; with the goal of eliminating a second full time ISS console support position by 2012. The team will also reduce one long range planning console position by 2014. When complete, these Flight Planning Branch projects will account for the elimination of 3 console positions and a reduction in staffing of 11 engineering personnel (EP) for ISS.

Hall, Timothy A.↗
NASA NTRS2011

NASA Technology Demonstrations Missions Program Overview

The National Aeronautics and Space Administration (NASA) Fiscal Year 2010 (FY10) budget introduced a new strategic plan that placed renewed emphasis on advanced missions beyond Earth orbit. This supports NASA s 2011 strategic goal to create innovative new space technologies for our exploration, science, and economic future. As a result of this focus on undertaking many and more complex missions, NASA placed its attention on a greater investment in technology development, and this shift resulted in the establishment of the Technology Demonstrations Missions (TDM) Program. The TDM Program, within the newly formed NASA Office of the Chief Technologist, supports NASA s grand challenges by providing a steady cadence of advanced space technology demonstrations (Figure 1), allowing the infusion of flexible path capabilities for future exploration. The TDM Program's goal is to mature crosscutting capabilities to flight readiness in support of multiple future space missions, including flight test projects where demonstration is needed before the capability can transition to direct mission The TDM Program has several unique criteria that set it apart from other NASA program offices. For instance, the TDM Office matures a small number of technologies that are of benefit to multiple customers to flight technology readiness level (TRL) 6 through relevant environment testing on a 3-year development schedule. These technologies must be crosscutting, which is defined as technology with potential to benefit multiple mission directorates, other government agencies, or the aerospace industry, and they must capture significant public interest and awareness. These projects will rely heavily on industry partner collaboration, and funding is capped for all elements of the flight test demonstration including planning, hardware development, software development, launch costs, ground operations, and post-test assessments. In order to inspire collaboration across government and industry, more than 70% of the TDM funds will be competitively awarded as a result of yearly calls for proposed flight demonstrators and selected based on possible payoff to NASA, technology maturity, customer interest, cost, and technical risk reduction. This paper will give an overview of the TDM Program s mission and organization, as well as its current status in delivering advanced space technologies that will enable more flexible and robust future missions. It also will provide several examples of missions that fit within these parameters and expected outcomes.

Turner, Susan↗
NASA NTRS2016

Enhancing the Cassini Mission Through FP Applications After Launch

Although rigorous pre-emptive measures are taken to preclude failures and anomalous conditions from occurring in JPL spacecraft missions prior to launch, unforeseeable problems can still surface after liftoff. In the case of the Cassini/Huygens Mission-to-Saturn spacecraft, several problems were observed post-launch: 1) immediately after takeoff, the collected engineering/science data stored on the Solid State Recorders (SSR) contained a significantly higher number of corrupted bits than was expected (considerably over spec) due to human error in the memory mapping of these devices, 2) numerous Solid State Power Switches (SSPS) sporadically tripped off throughout the mission due to cosmic ray bombardment from the unique space environment, and 3) false assumptions in the pressure regulator design in combination with missing heritage test data led to inaccurate design conclusions, causing the issuance of two waivers for the regulator to close properly (a potentially mission catastrophic single-point failure which occurred 24 days after launch) - amongst other problems. For Cassini, some of these anomalies led to arduous work-arounds or required continuous monitoring of telemetry variables by the ground-based Spacecraft Operations Flight Support (SOFS) team in order to detect and fix fault occurrences as they happened. Fortunately, sufficient funding and schedule margin allowed several Fault Protection (FP) solutions to be implemented into post-launch Flight Software (FSW) uploads to help resolve these issues autonomously, reducing SOFS ground support efforts while improving anomaly recovery time in order to preserve maximum science capture. This paper details the FP applications used to resolve the above issues as well as to optimize solutions for several other problems experienced by the Cassini spacecraft during its fight, in order to enhance the spacecraft's overall mission success throughout the 18 years of its 20 year expedition to and within the Saturnian system.

fault protection↗
NASA NTRS2012

Onboard Sensor Data Qualification in Human-Rated Launch Vehicles

The avionics system software for human-rated launch vehicles requires an implementation approach that is robust to failures, especially the failure of sensors used to monitor vehicle conditions that might result in an abort determination. Sensor measurements provide the basis for operational decisions on human-rated launch vehicles. This data is often used to assess the health of system or subsystem components, to identify failures, and to take corrective action. An incorrect conclusion and/or response may result if the sensor itself provides faulty data, or if the data provided by the sensor has been corrupted. Operational decisions based on faulty sensor data have the potential to be catastrophic, resulting in loss of mission or loss of crew. To prevent these later situations from occurring, a Modular Architecture and Generalized Methodology for Sensor Data Qualification in Human-rated Launch Vehicles has been developed. Sensor Data Qualification (SDQ) is a set of algorithms that can be implemented in onboard flight software, and can be used to qualify data obtained from flight-critical sensors prior to the data being used by other flight software algorithms. Qualified data has been analyzed by SDQ and is determined to be a true representation of the sensed system state; that is, the sensor data is determined not to be corrupted by sensor faults or signal transmission faults. Sensor data can become corrupted by faults at any point in the signal path between the sensor and the flight computer. Qualifying the sensor data has the benefit of ensuring that erroneous data is identified and flagged before otherwise being used for operational decisions, thus increasing confidence in the response of the other flight software processes using the qualified data, and decreasing the probability of false alarms or missed detections.

Wong, Edmond↗
NASA NTRS2012

SureTrak Probability of Impact Display

The SureTrak Probability of Impact Display software was developed for use during rocket launch operations. The software displays probability of impact information for each ship near the hazardous area during the time immediately preceding the launch of an unguided vehicle. Wallops range safety officers need to be sure that the risk to humans is below a certain threshold during each use of the Wallops Flight Facility Launch Range. Under the variable conditions that can exist at launch time, the decision to launch must be made in a timely manner to ensure a successful mission while not exceeding those risk criteria. Range safety officers need a tool that can give them the needed probability of impact information quickly, and in a format that is clearly understandable. This application is meant to fill that need. The software is a reuse of part of software developed for an earlier project: Ship Surveillance Software System (S4). The S4 project was written in C++ using Microsoft Visual Studio 6. The data structures and dialog templates from it were copied into a new application that calls the implementation of the algorithms from S4 and displays the results as needed. In the S4 software, the list of ships in the area was received from one local radar interface and from operators who entered the ship information manually. The SureTrak Probability of Impact Display application receives ship data from two local radars as well as the SureTrak system, eliminating the need for manual data entry.

Elliott, John↗
NASA NTRS2011

Content Documents Management

The Content Documents are created and managed under the System Software group with. Launch Control System (LCS) project. The System Software product group is lead by NASA Engineering Control and Data Systems branch (NE~C3) at Kennedy Space Center. The team is working on creating Operating System Images (OSI) for different platforms (i.e. AIX, Linux, Solaris and Windows). Before the OSI can be created, the team must create a Content Document which provides the information of a workstation or server, with the list of all the software that is to be installed on it and also the set where the hardware belongs. This can be for example in the LDS, the ADS or the FR-l. The objective of this project is to create a User Interface Web application that can manage the information of the Content Documents, with all the correct validations and filters for administrator purposes. For this project we used one of the most excellent tools in agile development applications called Ruby on Rails. This tool helps pragmatic programmers develop Web applications with Rails framework and Ruby programming language. It is very amazing to see how a student can learn about OOP features with the Ruby language, manage the user interface with HTML and CSS, create associations and queries with gems, manage databases and run a server with MYSQL, run shell commands with command prompt and create Web frameworks with Rails. All of this in a real world project and in just fifteen weeks!

Muniz, R.↗