Search NASA⌕ Search

SEARCH · Search NASA

Results for “flight software design”

Search indexed NASA NTRS and DOE OSTI research on propulsion, heat transfer, battery materials and energy systems. Follow report and document links to the original sources.

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

At least 145 records · Page 8

Software Considerations for Subscale Flight Testing of Experimental Control Laws

The NASA AirSTAR system has been designed to address the challenges associated with safe and efficient subscale flight testing of research control laws in adverse flight conditions. In this paper, software elements of this system are described, with an emphasis on components which allow for rapid prototyping and deployment of aircraft control laws. Through model-based design and automatic coding a common code-base is used for desktop analysis, piloted simulation and real-time flight control. The flight control system provides the ability to rapidly integrate and test multiple research control laws and to emulate component or sensor failures. Integrated integrity monitoring systems provide aircraft structural load protection, isolate the system from control algorithm failures, and monitor the health of telemetry streams. Finally, issues associated with software configuration management and code modularity are briefly discussed.

Murch, Austin M.↗

Research flight software engineering and MUST, an integrated system of support tools

Consideration is given to software development to support NASA flight research. The Multipurpose User-Oriented Software Technology (MUST) program, designed to integrate digital systems into flight research, is discussed. Particular attention is given to the program's special interactive user interface, subroutine library, assemblers, compiler, automatic documentation tools, and test and simulation subsystems.

Straeter, T. A.↗

User interactive electric propulsion software design

As electric propulsion technology matures from laboratory development to flight application, mission planners and spacecraft designers are increasingly required to determine the benefits and integration issues of using this propulsion capability. A computer software tool for supporting these analyses is presented. This tool combines detailed analytical models describing electric propulsion engine performance and subsystem design, and a software structure that is highly user interactive and adaptable. The software design methodology used to develop this software tool is presented in this paper.

Aston, Martha B.↗

Aircraft interrogation and display system: A ground support equipment for digital flight systems

A microprocessor-based general purpose ground support equipment for electronic systems was developed. The hardware and software are designed to permit diverse applications in support of aircraft flight systems and simulation facilities. The implementation of the hardware, the structure of the software, describes the application of the system to an ongoing research aircraft project are described.

Glover, R. D.↗

Software Design Methodology Migration for a Distributed Ground System

The Marshall Space Flight Center's (MSFC) Payload Operations Center (POC) ground system has been developed and has evolved over a period of about 10 years. During this time the software processes have migrated from more traditional to more contemporary development processes. The new Software processes still emphasize requirements capture, software configuration management, design documenting, and making sure the products that have been developed are accountable to initial requirements. This paper will give an overview of how the Software Process have evolved highlighting the positives as well as the negatives. In addition, we will mention the COTS tools that have been integrated into the processes and how the COTS have provided value to the project .

Ritter, George↗

Optics Program Simplifies Analysis and Design

Engineers at Goddard Space Flight Center partnered with software experts at Mide Technology Corporation, of Medford, Massachusetts, through a Small Business Innovation Research (SBIR) contract to design the Disturbance-Optics-Controls-Structures (DOCS) Toolbox, a software suite for performing integrated modeling for multidisciplinary analysis and design. The DOCS Toolbox integrates various discipline models into a coupled process math model that can then predict system performance as a function of subsystem design parameters. The system can be optimized for performance; design parameters can be traded; parameter uncertainties can be propagated through the math model to develop error bounds on system predictions; and the model can be updated, based on component, subsystem, or system level data. The Toolbox also allows the definition of process parameters as explicit functions of the coupled model and includes a number of functions that analyze the coupled system model and provide for redesign. The product is being sold commercially by Nightsky Systems Inc., of Raleigh, North Carolina, a spinoff company that was formed by Mide specifically to market the DOCS Toolbox. Commercial applications include use by any contractors developing large space-based optical systems, including Lockheed Martin Corporation, The Boeing Company, and Northrup Grumman Corporation, as well as companies providing technical audit services, like General Dynamics Corporation

Source record↗

X-57 Traction Power and Command Systems Development

This paper describes the final, as-built design of the X‑57 Maxwell aircraft power and command system architecture that implements the electrified propulsion capability. The development of the traction power, command, and avionics power subsystems proceeded as planned at the initial project critical design review, but improvements to the design were identified following the development of detailed operations concepts and integrated subsystem and system testing. The redundant architecture with A‑side and B‑side buses provided a robust framework for a developmental system that would turn out to have a lower technology readiness than had been assumed upon project formulation. As the project team identified reliability or performance gaps in the electrified propulsion powertrain components and their interactions with the other vehicle systems, the traction power, command, and avionics architectures were modified to accommodate the modified systems. Following the publication of the planned design approach at the critical design review milestone [1], the project team developed the flight hardware and software, integrated the systems, and adjusted the design and qualification activities to address gaps in the components, system architecture, and requirements as the gaps were realized. In addition to inherent challenges in development of these subsystems, the integration of this new technology with adjacent critical systems in an aircraft configuration posed additional challenges that drove design considerations across the subsystem development and the other vehicle systems. Integration complications included electromagnetic compatibility, thermal performance, and tolerance of single-point failures internal and external to the powerplant. Development of a qualification program was required for the new motors, inverters, and batteries, and hardware performance during component qualification fed back into the development process and led lessons learned and redesign of key elements.

distributed propulsion↗

Chapter 12 - Flight Envelope

The term "flight envelope" is used to refer to the boundaries of aircraft loading and flight conditions within which operation of the aircraft is satisfactory, and beyond which some aspect becomes unacceptable. This flight envelope represents, in fact, the limiting conditions arising from a matrix of inter-related flight envelopes covering the appropriate variables. Thus, for each loading (i.e., external stores configuration and its associated range of weight and center of gravity (c.g.) position) and aircraft configuration (i.e., position of undercarriage (u/c), flaps, slats, etc.), the envelopes of airspeed versus altitude, airspeed versus load factor, angle of attack versus angle of sideslip, etc., must be investigated to establish the limits within which all aspects such as handling qualities, engine behavior, structural loads, etc., remain acceptable. Flight testing of new or derivative aircraft models is carried out with the initial purpose of defining a flight envelope which is, first and foremost, safe and secondarily, which enables the effective use of the vehicle for its intended purpose. Flight testing occurs only after numerous reviews of the design and review of results from ground tests and predictions of flight characteristics in such areas as structures, aerodynamics, stability and control, flight controls (particularly fly-by-wire control systems, propulsion, etc.). Accordingly, opening and expanding the envelope is a task that must be approached cautiously, systematically, and with coordination and cooperation of the many disciplines involved in the design and test of an airplane. (Sections 8 and 10 cover test planning and safety of flight considerations, respectively). The fundamental tenet in establishing a flight envelope via flight test is risk reduction. This is reflected in the typical sequence of events leading to initial flight test - design reviews (both hardware and software), then ground test involving singular disciplines (windtunnel tests for aerodynamics, structurally loading the wing/fuselage/nacelle on a ground test article with loads anticipated to occur in flight, flight control system control law checkout, propulsion test cell runs and/or flying test bed tests, etc.), and then ground tests involving multi-disciplines (See Section 9). Only after these have been accomplished will an initial, limited, low-risk, flight envelope be established. The limited envelope will typically be in the middle of the projected final flight envelope. Subsequent flight tests will then be devoted to expanding the initial envelope by operating the airplane at increasing ranges - representing increasing risk - of engine operation, airspeeds both fast and slow, altitude, load factor both above and below 1g, centers of gravity (fore and aft), and with system/subsystem failures. Whether flight tests are to define a flight envelope on a new model airplane with the attendant new airframe, new engine(s), and new subsystems (hydraulics, pressurization, etc.), or on an airplane involving only a few of these areas such as new engines in an old airframe, the fundamental approach to establishing an envelope is the same.

H Walgemoed↗

MER : from landing to six wheels on Mars ... twice

Application of the Pathfinder landing system design to enclose the much larger Mars Exploration Rover required a variety of Rover deployments to achieve the surface driving configuration. The project schedule demanded that software design, engineering model test, and flight hardware build to be accomplished in parallel. This challenge was met through (a) bounding unknown environments against which to design and test, (b) early mechanical prototype testing, (c) constraining the scope of on-board autonomy to survival-critical deployments, (d) executing a balance of nominal and off-nominal test cases, (e) developing off-nominal event mitigation techniques before landing, (f) flexible replanning in response to surprises during operations. Here is discussed several specific events encountered during initial MER surface operations.

Mars Exploration Rover (MER)↗

The Cassini-Huygens Sequence Development Process

Each phase of the sequence development process had to overcome many operational challenges due to the immense complexity of the spacecraft, tour design, pointing capabilities, flight rules and software development. This paper will address the specific challenges related to each of those complexities and the methods used to overcome them during operation.

science planning↗

R-Hope: Development Approach to Extreme Non-volatile Memory Reuse Onboard the Curiosity Rover

The MSL Curiosity rover landed on Mars on August~5, 2012. Over time, one of its two computers experienced critical hardware memory failure. This non-volatile NAND flash memory held file system partitions and tunable parameters needed for running rover flight software. The project assembled a design and development team to re-purpose a NOR flash memory hardware chip, only 1.5\% of the size of the NAND, to hold the file systems and parameters. The usable NOR memory required major software changes to accommodate the new limitations of slower access speeds, vastly different physical layout, and smaller size. This presentation discusses the approach, challenges, and outcomes of restoring function to the computer so it can act as a ``lifeboat'' in event of problems with the primary computer.

Peper, Nick↗

Interplanetary Overlay Network Bundle Protocol Implementation

The Interplanetary Overlay Network (ION) system's BP package, an implementation of the Delay-Tolerant Networking (DTN) Bundle Protocol (BP) and supporting services, has been specifically designed to be suitable for use on deep-space robotic vehicles. Although the ION BP implementation is unique in its use of zero-copy objects for high performance, and in its use of resource-sensitive rate control, it is fully interoperable with other implementations of the BP specification (Internet RFC 5050). The ION BP implementation is built using the same software infrastructure that underlies the implementation of the CCSDS (Consultative Committee for Space Data Systems) File Delivery Protocol (CFDP) built into the flight software of Deep Impact. It is designed to minimize resource consumption, while maximizing operational robustness. For example, no dynamic allocation of system memory is required. Like all the other ION packages, ION's BP implementation is designed to port readily between Linux and Solaris (for easy development and for ground system operations) and VxWorks (for flight systems operations). The exact same source code is exercised in both environments. Initially included in the ION BP implementations are the following: libraries of functions used in constructing bundle forwarders and convergence-layer (CL) input and output adapters; a simple prototype bundle forwarder and associated CL adapters designed to run over an IPbased local area network; administrative tools for managing a simple DTN infrastructure built from these components; a background daemon process that silently destroys bundles whose time-to-live intervals have expired; a library of functions exposed to applications, enabling them to issue and receive data encapsulated in DTN bundles; and some simple applications that can be used for system checkout and benchmarking.

Burleigh, Scott C.↗

Safety considerations in the design of manned spaceflight hardware

Some of the significant potential hazards affecting NASA's planned space-flight initiatives are discussed together with the safety design strategies they mandate. Attention is given to the role played by NASA's newly centralized safety organization during the design of manned space flight hardware and software. Prompt-effect/physical hazards include fire, explosions and depressurization, and natural and man-made space debris. Delayed-effect hazards include radiation and toxic contamination, microgravity effects, crew illness and injury, and isolation. Safety design considerations for software and hypersonic transatmospheric vehicles are evaluated.

Rodney, G. A.↗

Hardware Verification and Validation for a Navigation Sensor Software Model in Support of Flight Vehicle Performance Analysis

… or, “It’s in the details, how to make complicated software perform like complicated hardware.” In attempts to minimize development time and quickly build an operational vehicle, NASA’s Space Launch System (SLS) has had to be intentional about integrated testing. Constraints on budget and schedule have required balance between testing needs and the desire for an integrated flight vehicle as soon as possible. To provide key insights early in design and analysis cycles, a large amount of effort has shifted into maturing and validating models at the component level with integrated testing as a means to validate their integration. In terms of SLS Navigation, this, and the model-based design approach have pushed explicit requirements for sensor models to be validated against flight hardware to high precision. This paper covers the approach taken to verify and validate the models for the two key navigation sensors on the SLS vehicle, the Redundant Inertial Navigation Sensor and the Rate Gyro Assembly. These models are used in performance evaluation, fault detection, and operations development extensively. Using a mix of data from hardware vendor documentation and testing reports, limited in-house testing, and integration activities, these models were able to be validated against flight hardware at multiple levels, from the internal software design to statistical behavior at the raw sensor and integrated box levels. The high level of insight into the hardware elements is instrumental to support flight certification activities and building confidence in SLS Navigation capability. Focused testing enabled additional insight and validation that proved invaluable and the resulting insights were used to focus and mature models. Additionally, of having validated performance-based hardware models enables a wide breadth of activities including detailed fault detection studies and integration into future vehicle frameworks, such as an upper stage and provide a valuable asset to continued SLS analysis and design.

Evan J Anzalone↗

Hardware Verification and Validation for a Navigation Sensor Software Model in Support of Flight Vehicle Performance Analysis

… or, “It’s in the details, how to make complicated software perform like complicated hardware.” In attempts to minimize development time and quickly build an operational vehicle, NASA’s Space Launch System (SLS) has had to be intentional about integrated testing. Constraints on budget and schedule have required balance between testing needs and the desire for an integrated flight vehicle as soon as possible. To provide key insights early in design and analysis cycles, a large amount of effort has shifted into maturing and validating models at the component level with integrated testing as a means to validate their integration. In terms of SLS Navigation, this, and the model-based design approach have pushed explicit requirements for sensor models to be validated against flight hardware to high precision. This paper covers the approach taken to verify and validate the models for the two key navigation sensors on the SLS vehicle, the Redundant Inertial Navigation Sensor and the Rate Gyro Assembly. These models are used in performance evaluation, fault detection, and operations development extensively. Using a mix of data from hardware vendor documentation and testing reports, limited in-house testing, and integration activities, these models were able to be validated against flight hardware at multiple levels, from the internal software design to statistical behavior at the raw sensor and integrated box levels. The high level of insight into the hardware elements is instrumental to support flight certification activities and building confidence in SLS Navigation capability. Focused testing enabled additional insight and validation that proved invaluable and the resulting insights were used to focus and mature models. Additionally, of having validated performance-based hardware models enables a wide breadth of activities including detailed fault detection studies and integration into future vehicle frameworks, such as an upper stage and provide a valuable asset to continued SLS analysis and design.

Thomas Park↗

The Software Design for the Wide-Field Infrared Explorer Attitude Control System

The Wide-Field Infrared Explorer (WIRE), currently scheduled for launch in September 1998, is the fifth of five spacecraft in the NASA/Goddard Small Explorer (SMEX) series. This paper presents the design of WIRE's Attitude Control System flight software (ACS FSW). WIRE is a momentum-biased, three-axis stabilized stellar pointer which provides high-accuracy pointing and autonomous acquisition for eight to ten stellar targets per orbit. WIRE's short mission life and limited cryogen supply motivate requirements for Sun and Earth avoidance constraints which are designed to prevent catastrophic instrument damage and to minimize the heat load on the cryostat. The FSW implements autonomous fault detection and handling (FDH) to enforce these instrument constraints and to perform several other checks which insure the safety of the spacecraft. The ACS FSW implements modules for sensor data processing, attitude determination, attitude control, guide star acquisition, actuator command generation, command/telemetry processing, and FDH. These software components are integrated with a hierarchical control mode managing module that dictates which software components are currently active. The lowest mode in the hierarchy is the 'safest' one, in the sense that it utilizes a minimal complement of sensors and actuators to keep the spacecraft in a stable configuration (power and pointing constraints are maintained). As higher modes in the hierarchy are achieved, the various software functions are activated by the mode manager, and an increasing level of attitude control accuracy is provided. If FDH detects a constraint violation or other anomaly, it triggers a safing transition to a lower control mode. The WIRE ACS FSW satisfies all target acquisition and pointing accuracy requirements, enforces all pointing constraints, provides the ground with a simple means for reconfiguring the system via table load, and meets all the demands of its real-time embedded environment (16 MHz Intel 80386 processor with 80387 coprocessor running under the VRTX operating system). The mode manager organizes and controls all the software modules used to accomplish these goals, and in particular, the FDH module is tightly coupled with the mode manager.

Anderson, Mark O.↗

Minimum testing of the space shuttle orbiter for stability and control derivatives

A unique approach has been developed for stability and control derivative testing of the Space Shuttle orbiter during entry. Shuttle Program requirements have necessitated a minimum of testing. Therefore, flight tests concentrate on potential control problem areas predicted from wind tunnel data as well as anomalies discovered during flight testing. The object is to use the test data to remove center of gravity (cg), angle of attack, and elevon placards which are a function of these potential control problems. To ensure successful aerodynamic extraction from a minimum of testing, the following special measures have been taken. Exact maneuvers are designed preflight on Shuttle simulators. These maneuvers are duplicated and implemented during the flight by onboard software. An onboard instrumentation system was designed especially for aerodynamic parameter identification. State-of-the-art techniques are used in extracting aerodynamics.

Cooke, D. R.↗

The Ejectable Data Recorder: A Lean, Risk-Informed Approach for Hardware Development

NASA is developing the Orion spacecraft to transport crew from the Earth to the Moon as part of the Artemis series of missions. To provide a crew escape capability from pre-launch through ascent, the Orion vehicle is equipped with a Launch Abort System (LAS), built by Lockheed Martin, which pulls the capsule away from the launch vehicle in the event of an abort scenario. The Ascent Abort 2 (AA-2) test flight occurred on July 2, 2019,and tested a production version of the LAS to ensure that it can operate as intended, and to collect a large data set from hundreds of sensors on the vehicle to support Orion flight certification. In the original AA-2 architecture, a single-string set of communications antennas on the LAS would downlink all of the in-flight test data to ground stations. However, that communications architecture was predicted to have data dropouts during abort and jettison of the LAS, and would not support data transmission at all after LAS jettison. As a result, a comprehensive trade study was completed, yielding the addition of antennas on the crew module (CM), a buffer/rebroadcast capability for key portions of the flight, and an ejectable data recorder (EDR) subsystem. This EDR subsystem would serve as a backup to the radio frequency (RF) communications system, and would be non-flight critical, providing a unique capability that enabled management to take a different approach with the hardware and software development. The Crew Module and Separation Ring were developed as “Class 1”Flight Hardware, albeit with some tailoring approaches to enable efficiencies. The Class 1 designation requires full rigor for flight hardware and software, documenting everything that happens to a piece of hardware from procurement through disposal, requiring a full spectrum of acceptance tests, and the highest rigor of quality assurance processes. At the other end of the spectrum, Class 3hardware is controlled, but not intended for flight, and leaves the level of rigor up to the project manager. This classification is often used for research and development projects. Similarly,Class-1E has been recently defined at NASA for ISS payloads and technology development projects that are not flight critical and do not need the full rigor of Class 1 to be successful. The EDR subsystem was challenged at commencement to adopt a skunkworks and agile-like approach to hardware development, allowing for a different risk posture than the rest of the AA-2 hardware. After initially pursuing Class 1 processes, the EDR subsystem design evolved to incorporating numerous commercial components, leading to re-designation as a Class-1E subsystem. The resulting EDR subsystem was fully successful in meeting all flight system requirements, and achieved 100% retrieval of flight test data. This paper will discuss the risk posture of the EDR subsystem and the subsequent tailoring that was enacted as part of its Class-1E status.

EDR↗