Search NASA⌕ Search

SEARCH · Search NASA

Results for “flight softwar”

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 595 records · Page 33

An Automated Method to Compute Orbital Re-entry Trajectories with Heating Constraints

Determining how to properly manipulate the controls of a re-entering re-usable launch vehicle (RLV) so that it is able to safely return to Earth and land involves the solution of a two-point boundary value problem (TPBVP). This problem, which can be quite difficult, is traditionally solved on the ground prior to flight. If necessary, a nearly unlimited amount of time is available to find the 'best' solution using a variety of trajectory design and optimization tools. The role of entry guidance during flight is to follow the pre- determined reference solution while correcting for any errors encountered along the way. This guidance method is both highly reliable and very efficient in terms of onboard computer resources. There is a growing interest in a style of entry guidance that places the responsibility of solving the TPBVP in the actual entry guidance flight software. Here there is very limited computer time. The powerful, but finicky, mathematical tools used by trajectory designers on the ground cannot in general be converted to do the job. Non-convergence or slow convergence can result in disaster. The challenges of designing such an algorithm are numerous and difficult. Yet the payoff (in the form of decreased operational costs and increased safety) can be substantiaL This paper presents an algorithm that incorporates features of both types of guidance strategies. It takes an initial RLV orbital re-entry state and finds a trajectory that will safely transport the vehicle to Earth. During actual flight, the computed trajectory is used as the reference to be flown by a more traditional guidance method.

Zimmerman, Curtis↗

GOES-R Active Vibration Damping Controller Design, Implementation, and On-Orbit Performance

GOES-R series spacecraft feature a number of flexible appendages with modal frequencies below 3.0 Hz which, if excited by spacecraft disturbances, can be sources of undesirable jitter perturbing spacecraft pointing. In order to meet GOES-R pointing stability requirements, the spacecraft flight software implements an Active Vibration Damping (AVD) rate control law which acts in parallel with the nadir point attitude control law. The AVD controller commands spacecraft reaction wheel actuators based upon Inertial Measurement Unit (IMU) inputs to provide additional damping for spacecraft structural modes below 3.0 Hz which vary with solar wing angle. A GOES-R spacecraft dynamics and attitude control system identified model is constructed from pseudo-random reaction wheel torque commands and IMU angular rate response measurements occurring over a single orbit during spacecraft post-deployment activities. The identified Fourier model is computed on the ground, uplinked to the spacecraft flight computer, and the AVD controller filter coefficients are periodically computed on-board from the Fourier model. Consequently, the AVD controller formulation is based not upon pre-launch simulation model estimates but upon on-orbit nadir point attitude control and time-varying spacecraft dynamics. GOES-R high-fidelity time domain simulation results herein demonstrate the accuracy of the AVD identified Fourier model relative to the pre-launch spacecraft dynamics and control truth model. The AVD controller on-board the GOES-16 spacecraft achieves more than a ten-fold increase in structural mode damping of the fundamental solar wing mode while maintaining controller stability margins and ensuring that the nadir point attitude control bandwidth does not fall below 0.02 Hz. On-orbit GOES-16 spacecraft appendage modal frequencies and damping ratios are quantified based upon the AVD system identification, and the increase in modal damping provided by the AVD controller for each structural mode is presented. The GOES-16 spacecraft AVD controller frequency domain stability margins and nadir point attitude control bandwidth are presented along with on-orbit time domain disturbance response performance.

Active Vibration Damping↗

Interface Generation and Compositional Verification in JavaPathfinder

We present a novel algorithm for interface generation of software components. Given a component, our algorithm uses learning techniques to compute a permissive interface representing legal usage of the component. Unlike our previous work, this algorithm does not require knowledge about the component s environment. Furthermore, in contrast to other related approaches, our algorithm computes permissive interfaces even in the presence of non-determinism in the component. Our algorithm is implemented in the JavaPathfinder model checking framework for UML statechart components. We have also added support for automated assume-guarantee style compositional verification in JavaPathfinder, using component interfaces. We report on the application of the presented approach to the generation of interfaces for flight software components.

Giannakopoulou, Dimitra↗

An Automated Method to Compute Orbital Re-Entry Trajectories with Heating Constraints

Determining how to properly manipulate the controls of a re-entering re-usable launch vehicle (RLV) so that it is able to safely return to Earth and land involves the solution of a two-point boundary value problem (TPBVP). This problem, which can be quite difficult, is traditionally solved on the ground prior to flight. If necessary, a nearly unlimited amount of time is available to find the "best" solution using a variety of trajectory design and optimization tools. The role of entry guidance during flight is to follow the pre-determined reference solution while correcting for any errors encountered along the way. This guidance method is both highly reliable and very efficient in terms of onboard computer resources. There is a growing interest in a style of entry guidance that places the responsibility of solving the TPBVP in the actual entry guidance flight software. Here there is very limited computer time. The powerful, but finicky, mathematical tools used by trajectory designers on the ground cannot in general be made to do the job. Nonconvergence or slow convergence can result in disaster. The challenges of designing such an algorithm are numerous and difficult. Yet the payoff (in the form of decreased operational costs and increased safety) can be substantial. This paper presents an algorithm that incorporates features of both types of guidance strategies. It takes an initial RLV orbital re-entry state and finds a trajectory that will safely transport the vehicle to a Terminal Area Energy Management (TAEM) region. During actual flight, the computed trajectory is used as the reference to be flown by a more traditional guidance method.

Zimmerman, Curtis↗

6DOF Testing of the SLS Inertial Navigation Unit

The Navigation System on the NASA Space Launch System (SLS) Block 1 vehicle performs initial alignment of the Inertial Navigation System (INS) navigation frame through gyrocompass alignment (GCA). Because the navigation architecture for the SLS Block 1 vehicle is a purely inertial system, the accuracy of the achieved orbit relative to mission requirements is very sensitive to initial alignment accuracy. The assessment of this sensitivity and many others via simulation is a part of the SLS Model-Based Design and Model-Based Requirements approach. As a part of the aforementioned, 6DOF Monte Carlo simulation is used in large part to develop and demonstrate verification of program requirements. To facilitate this and the GN&C flight software design process, an SLS-Program-controlled Design Math Model (DMM) of the SLS INS was developed by the SLS Navigation Team. The SLS INS model implements all of the key functions of the hardware-namely, GCA, inertial navigation, and FDIR (Fault Detection, Isolation, and Recovery)-in support of SLS GN&C design requirements verification. Despite the strong sensitivity to initial alignment, GCA accuracy requirements were not verified by test due to program cost and schedule constraints. Instead, the system relies upon assessments performed using the SLS INS model. In order to verify SLS program requirements by analysis, the SLS INS model is verified and validated against flight hardware. In lieu of direct testing of GCA accuracy in support of requirement verification, the SLS Navigation Team proposed and conducted an engineering test to, among other things, validate the GCA performance and overall behavior of the SLS INS model through comparison with test data. This paper will detail dynamic hardware testing of the SLS INS, conducted by the SLS Navigation Team at Marshall Space Flight Center's 6DOF Table Facility, in support of GCA performance characterization and INS model validation. A 6-DOF motion platform was used to produce 6DOF pad twist and sway dynamics while a simulated SLS flight computer communicated with the INS. Tests conducted include an evaluation of GCA algorithm robustness to increasingly dynamic pad environments, an examination of GCA algorithm stability and accuracy over long durations, and a long-duration static test to gather enough data for Allan Variance analysis. Test setup, execution, and data analysis will be discussed, including analysis performed in support of SLS INS model validation.

Geohagan, Kevin↗

Rapid Diagnostics of Onboard Sequences

Keeping track of sequences onboard a spacecraft is challenging. When reviewing Event Verification Records (EVRs) of sequence executions on the Mars Exploration Rover (MER), operators often found themselves wondering which version of a named sequence the EVR corresponded to. The lack of this information drastically impacts the operators diagnostic capabilities as well as their situational awareness with respect to the commands the spacecraft has executed, since the EVRs do not provide argument values or explanatory comments. Having this information immediately available can be instrumental in diagnosing critical events and can significantly enhance the overall safety of the spacecraft. This software provides auditing capability that can eliminate that uncertainty while diagnosing critical conditions. Furthermore, the Restful interface provides a simple way for sequencing tools to automatically retrieve binary compiled sequence SCMFs (Space Command Message Files) on demand. It also enables developers to change the underlying database, while maintaining the same interface to the existing applications. The logging capabilities are also beneficial to operators when they are trying to recall how they solved a similar problem many days ago: this software enables automatic recovery of SCMF and RML (Robot Markup Language) sequence files directly from the command EVRs, eliminating the need for people to find and validate the corresponding sequences. To address the lack of auditing capability for sequences onboard a spacecraft during earlier missions, extensive logging support was added on the Mars Science Laboratory (MSL) sequencing server. This server is responsible for generating all MSL binary SCMFs from RML input sequences. The sequencing server logs every SCMF it generates into a MySQL database, as well as the high-level RML file and dictionary name inputs used to create the SCMF. The SCMF is then indexed by a hash value that is automatically included in all command EVRs by the onboard flight software. Second, both the binary SCMF result and the RML input file can be retrieved simply by specifying the hash to a Restful web interface. This interface enables command line tools as well as large sophisticated programs to download the SCMF and RMLs on-demand from the database, enabling a vast array of tools to be built on top of it. One such command line tool can retrieve and display RML files, or annotate a list of EVRs by interleaving them with the original sequence commands. This software has been integrated with the MSL sequencing pipeline where it will serve sequences useful in diagnostics, debugging, and situational awareness throughout the mission.

Starbird, Thomas W.↗

Agent Based Software for the Autonomous Control of Formation Flying Spacecraft

Distributed satellite systems is an enabling technology for many future NASA/DoD earth and space science missions, such as MMS, MAXIM, Leonardo, and LISA [1, 2, 3]. While formation flying offers significant science benefits, to reduce the operating costs for these missions it will be essential that these multiple vehicles effectively act as a single spacecraft by performing coordinated observations. Autonomous guidance, navigation, and control as part of a coordinated fleet-autonomy is a key technology that will help accomplish this complex goal. This is no small task, as most current space missions require significant input from the ground for even relatively simple decisions such as thruster burns. Work for the NMP DS1 mission focused on the development of the New Millennium Remote Agent (NMRA) architecture for autonomous spacecraft control systems. NMRA integrates traditional real-time monitoring and control with components for constraint-based planning, robust multi-threaded execution, and model-based diagnosis and reconfiguration. The complexity of using an autonomous approach for space flight software was evident when most of its capabilities were stripped off prior to launch (although more capability was uplinked subsequently, and the resulting demonstration was very successful).

How, Jonathan P.↗

Productivity Challenges for Mars Rover Operations

Achieving consistently high levels of productivity for surface exploration missions has been a challenge for Mars missions. While the rovers have made major discoveries and accomplished a large number of objectives, they often require a great deal of effort from the operations teams and achievingobjectives can take longer than anticipated. This paper describes the early stages of a multi-year project to investigate solutions for enhancing surface mission productivity. A primary focus of this early stage is to conduct in-depth studies of Mars Science Laboratory science campaigns to gain a deeper understanding of the factors that impact productivity, and to use this understanding to identify potential changes to flight software and ground operations practices to increase productivity. We present the science campaigns we have selected along with a conceptual model of how surface missions achieve objectives that is used to guide the study. We also provide some early thoughts on the technologies, and their interactions, which we believe will play an important role in addressing surface mission productivity challenges.We are in the early stages of a multi-year project to studyand address productivity challenges of future surface missions. We have identified campaigns from the MSL missionfor study which we believe will yield valuable informationabout the nature of surface mission productivity challenges.Based on preliminary analysis from the data collected weanticipate that the lessons from these case studies will helpdevelop and mature our concepts for changes to flight andground systems to address these challenges.While the focus of our work is on Mars rover missions, webelieve the concepts in the work will be applicable to a variety of in-situ explorers, including Venus, and Titan, as wellas orbital missions, such as the Europa orbiter. These missions will also benefit from the ability to adapt and respondto the latest state of the spacecraft and its environment.

Gaines, Daniel↗

Space shuttle orbiter guidance, naviagation and control software functional requirements: Horizontal flight operations

The shuttle GN&C software functions for horizontal flight operations are defined. Software functional requirements are grouped into two categories: first horizontal flight requirements and full mission horizontal flight requirements. The document privides the intial step in the shuttle GN&C software design process. It also serves as a management tool to identify analyses which are required to define requirements.

Source record↗

Orbital flight simulation utility software unit specifications

The HP PASCAL source code contained in pages 6 through 104 was developed for the Mission Planning and Analysis Division (MPAD) and takes the place of detailed flow charts defining the specifications for a Utility Software Unit designed to support orbital flight simulators such as MANHANDLE and GREAS (General Research and Engineering Analysis Simulator). Besides providing basic input/output, mathematical, vector, matrix, quaternion, and statistical routines for such simulators, one of the primary functions of the Utility Software Unit is to isolate all system-dependent code in one well-defined compartment, thereby facilitating transportation of the simulations from one computer to another. Directives to the PASCAL compilers of the HP-9000 Series 200 PASCAL 3.0 operating system and the HP-9000 Series 500 HP-UX 5.0 operations systems are also provided.

Wilson, S. W.↗

Historical Aerospace Software Errors Categorized to Influence Fault Tolerance

Since the first use of computers in space and aircraft, software errors have occurred. These errors can manifest as loss-of-life or less catastrophically. As the demand for automation increases, software in mission or safety-critical systems should be designed to be tolerant to the most likely software faults. This paper categorizes a set of 55 historic aerospace software error incidents from 1962 to 2023 to determine trends of how and where automation is most likely to fail, behaving unexpectedly. A distinction between software producing unexpected (erroneous) output versus no output (failsilent) is introduced. Of the historical incidents analyzed, 85% were from software producing wrong output rather than simply stopping. Rebooting was found to be ineffective to clear erroneous behavior, and not reliable to recover from silent failures. Error origin was within the code/logic itself in 58% of cases, 16% from configurable data, 15% from unexpected sensor input, and 11% from command/operator input. A substantial forty percent (40%) of unexpected software behavior was indicated by the absence of code, arising from unanticipated situations and missing requirements, and 16% of incidents were subjectively deemed “unknown-unknowns”. No incidents were found to be the result of programming language, compiler, tool, or operating system; and only sixteen percent (16%) of all incidents were considered errors traditional computer science/programming in nature. These findings indicate that for fault tolerance, erroneous automation behavior must be a primary consideration especially at critical moments, and reboot recoverability may not be viable. Special care should be taken to validate configurable data and commands prior to use. “Test-like-you-fly”, including hardware-in-the-loop combined with robust off-nominal testing should be used to uncover missing logic arising from unanticipated situations not covered by requirements alone. This study uniquely focuses on manifestations of unexpected flight software behavior, independent of ultimate root cause. We characterize software error behavior and origin to improve software design, test, and operations for resilience to the most common manifestations, and provide a rich dataset for further study.

Aerospace↗

Orion MPCV Touchdown Detection Threshold Development and Testing

A robust method of detecting Orion Multi ]Purpose Crew Vehicle (MPCV) splashdown is necessary to ensure crew and hardware safety during descent and after touchdown. The proposed method uses a triple redundant system to inhibit Reaction Control System (RCS) thruster firings, detach parachute risers from the vehicle, and transition to the post ]landing segment of the Flight Software (FSW). The vehicle crew is the prime input for touchdown detection, followed by an autonomous FSW algorithm, and finally a strictly time based backup timer. RCS thrusters must be inhibited before submersion in water to protect against possible damage due to firing these jets under water. In addition, neglecting to declare touchdown will not allow the vehicle to transition to post ]landing activities such as activating the Crew Module Up ]righting System (CMUS), resulting in possible loss of communication and difficult recovery. A previous AIAA paper gAssessment of an Automated Touchdown Detection Algorithm for the Orion Crew Module h concluded that a strictly Inertial Measurement Unit (IMU) based detection method using an acceleration spike algorithm had the highest safety margins and shortest detection times of other methods considered. That study utilized finite element simulations of vehicle splashdown, generated by LS ]DYNA, which were expanded to a larger set of results using a Kriging surface fit. The study also used the Decelerator Systems Simulation (DSS) to generate flight dynamics during vehicle descent under parachutes. Proto ]type IMU and FSW MATLAB models provided the basis for initial algorithm development and testing. This paper documents an in ]depth trade study, using the same dynamics data and MATLAB simulations as the earlier work, to further develop the acceleration detection method. By studying the combined effects of data rate, filtering on the rotational acceleration correction, data persistence limits and values of acceleration thresholds, an optimal configuration was determined. The lever arm calculation, which removes the centripetal acceleration caused by vehicle rotation, requires that the vehicle angular acceleration be derived from vehicle body rates, necessitating the addition of a 2nd order filter to smooth the data. It was determined that using 200 Hz data directly from the vehicle IMU outperforms the 40 Hz FSW data rate. Data persistence counter values and acceleration thresholds were balanced in order to meet desired safety and performance. The algorithm proved to exhibit ample safety margin against early detection while under parachutes, and adequate performance upon vehicle splashdown. Fall times from algorithm initiation were also studied, and a backup timer length was chosen to provide a large safety margin, yet still trigger detection before CMUS inflation. This timer serves as a backup to the primary acceleration detection method. Additionally, these parameters were tested for safety on actual flight test data, demonstrating expected safety margins.

Daum, Jared↗

Risk Management Implementation Tool

Continuous Risk Management (CM) is a software engineering practice with processes, methods, and tools for managing risk in a project. It provides a controlled environment for practical decision making, in order to assess continually what could go wrong, determine which risk are important to deal with, implement strategies to deal with those risk and assure the measure effectiveness of the implemented strategies. Continuous Risk Management provides many training workshops and courses to teach the staff how to implement risk management to their various experiments and projects. The steps of the CRM process are identification, analysis, planning, tracking, and control. These steps and the various methods and tools that go along with them, identification, and dealing with risk is clear-cut. The office that I worked in was the Risk Management Office (RMO). The RMO at NASA works hard to uphold NASA s mission of exploration and advancement of scientific knowledge and technology by defining and reducing program risk. The RMO is one of the divisions that fall under the Safety and Assurance Directorate (SAAD). I worked under Cynthia Calhoun, Flight Software Systems Engineer. My task was to develop a help screen for the Continuous Risk Management Implementation Tool (RMIT). The Risk Management Implementation Tool will be used by many NASA managers to identify, analyze, track, control, and communicate risks in their programs and projects. The RMIT will provide a means for NASA to continuously assess risks. The goals and purposes for this tool is to provide a simple means to manage risks, be used by program and project managers throughout NASA for managing risk, and to take an aggressive approach to advertise and advocate the use of RMIT at each NASA center.

Wright, Shayla L.↗

Evolution of Software-Only-Simulation at NASA IV and V

Software-Only-Simulations have been an emerging but quickly developing field of study throughout NASA. The NASA Independent Verification Validation (IVV) Independent Test Capability (ITC) team has been rapidly building a collection of simulators for a wide range of NASA missions. ITC specializes in full end-to-end simulations that enable developers, VV personnel, and operators to test-as-you-fly. In four years, the team has delivered a wide variety of spacecraft simulations that have ranged from low complexity science missions such as the Global Precipitation Management (GPM) satellite and the Deep Space Climate Observatory (DSCOVR), to the extremely complex missions such as the James Webb Space Telescope (JWST) and Space Launch System (SLS).This paper describes the evolution of ITCs technologies and processes that have been utilized to design, implement, and deploy end-to-end simulation environments for various NASA missions. A comparison of mission simulators are discussed with focus on technology and lessons learned in complexity, hardware modeling, and continuous integration. The paper also describes the methods for executing the missions unmodified flight software binaries (not cross-compiled) for verification and validation activities.

Embedded↗

Ensuring Flexibility and Security in SDN-Based Spacecraft Communication Networks Through Risk Assessment

Software-defined networking (SDN) has enabled elastic networking and resource distribution in cloud computing. The centralization and separation of the Control Plane also offers a high degree of network configurability and management, which can be used to mitigate and manage threats to the network. Space communication networks have historically been restricted and circuit switching in these networks has been a manual process. This study evaluates the potential role of SDN in space communication networks from a networking security standpoint. The evaluation covers the networking security needs of spacecraft missions and their associated assets. The results from the evaluation lead to a risk assessment that identifies vulnerabilities in an SDN-based communications architecture. Security challenges introduced into the network from integrating SDN are also considered. A risk register summarizes the severity of the attack outcomes, as well as occurrence likelihood. The study identifies Denial-of-Service (DoS) attacks as a new threat (presently unmitigated by existing security controls) that would be prevalent in an SDN-based space communication environment. A Mininet-based emulation testbed is built to demonstrate the susceptibility of spacecraft flight software to a flooding DoS attack when on an interconnected SDN-managed network. This type of attack would be highly consequential to mission assets, and therefore SDN-based space communications would need to be resilient to such attacks. Future work will need to be performed to fully characterize DoS attack methods that can apply to the space communication scenario, as well as to devise a comprehensive DoS-resilient solution.

Baker, Dylan Z.↗

Orion MPCV Touchdown Detection Threshold Development and Testing

A robust method of detecting Orion Multi-Purpose Crew Vehicle (MPCV) splashdown is necessary to ensure crew and hardware safety during descent and after touchdown. The proposed method uses a triple redundant system to inhibit Reaction Control System (RCS) thruster firings, detach parachute risers from the vehicle, and transition to the post-landing segment of the Flight Software (FSW). An in-depth trade study was completed to determine optimal characteristics of the touchdown detection method resulting in an algorithm monitoring filtered, lever-arm corrected, 200 Hz Inertial Measurement Unit (IMU) vehicle acceleration magnitude data against a tunable threshold using persistence counter logic. Following the design of the algorithm, high fidelity environment and vehicle simulations, coupled with the actual vehicle FSW, were used to tune the acceleration threshold and persistence counter value to result in adequate performance in detecting touchdown and sufficient safety margin against early detection while descending under parachutes. An analytical approach including Kriging and adaptive sampling allowed for a sufficient number of finite element analysis (FEA) impact simulations to be completed using minimal computation time. The combination of a persistence counter of 10 and an acceleration threshold of approximately 57.3 ft/s2 resulted in an impact performance factor of safety (FOS) of 1.0 and a safety FOS of approximately 2.6 for touchdown declaration. An RCS termination acceleration threshold of approximately 53.1 ft/s(exp)2 with a persistence counter of 10 resulted in an increased impact performance FOS of 1.2 at the expense of a lowered under-parachutes safety factor of 2.2. The resulting tuned algorithm was then tested on data from eight Capsule Parachute Assembly System (CPAS) flight tests, showing an experimental minimum safety FOS of 6.1. The formulated touchdown detection algorithm will be flown on the Orion MPCV FSW during the Exploration Flight Test 1 (EFT-1) mission in the second half of 2014.

Daum, Jared↗

Apollo experience report: Mission planning for Apollo entry

The problems encountered and the experience gained in the entry mission plans, flight software, trajectory-monitoring procedures, and backup trajectory-control techniques of the Apollo Program should provide a foundation upon which future spacecraft programs can be developed. Descriptions of these entry activities are presented. Also, to provide additional background information needed for discussion of the Apollo entry experience, descriptions of the entry targeting for the Apollo 11 mission and the postflight analysis of the Apollo 10 mission are presented.

Graves, C. A.↗

GOAL-to-HAL translation study

This report deals with the feasibility, problems, solutions, and mapping of a GOAL language to HAL language translator. Ground Operations Aerospace Language, or GOAL, is a test-oriented higher order language developed by the John F. Kennedy Space Center to be used in checkout and launch of the space shuttle. HAL is a structured higher order language developed by the Johnson Space Center to be used in writing the flight software for the onboard shuttle computers. Since the onboard computers will extensively support ground checkout of the space shuttle, and since these computers and the software development facilities on the ground use the HAL language as baseline, the translation of GOAL to HAL becomes significant. The issue of feasibility was examined and it was found that a GOAL to HAL translator is feasible. Special problems are identified and solutions proposed. Finally, examples of translation are provided for each category of complete GOAL statement.

Flanders, J. H.↗