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.

SourceResearch connectionFrom yearThrough year

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

At least 217 records · Page 12

All sources NASA NTRS DOE OSTI

NASA NTRS2006

NASA Crew Launch Vehicle Flight Test Process

Davis, Stephan R.↗

NASA NTRS2007

Ares I-X Flight Test Philosophy

In response to the Vision for Space Exploration, the National Aeronautics and Space Administration (NASA) has defined a new space exploration architecture to return humans to the Moon and prepare for human exploration of Mars. One of the first new developments will be the Ares I Crew Launch Vehicle (CLV), which will carry the Orion Crew Exploration Vehicle (CEV), into Low Earth Orbit (LEO) to support International Space Station (ISS) missions and, later, support lunar missions. As part of Ares I development, NASA will perform a series of Ares I flight tests. The tests will provide data that will inform the engineering and design process and verify the flight hardware and software. The data gained from the flight tests will be used to certify the new Ares/Orion vehicle for human space flight. The primary objectives of this first flight test (Ares I-X) are the following: Demonstrate control of a dynamically similar integrated Ares CLV/Orion CEV using Ares CLV ascent control algorithms; Perform an in-flight separation/staging event between an Ares I-similar First Stage and a representative Upper Stage; Demonstrate assembly and recovery of a new Ares CLV-like First Stage element at Kennedy Space Center (KSC); Demonstrate First Stage separation sequencing, and quantify First Stage atmospheric entry dynamics and parachute performance; and Characterize the magnitude of the integrated vehicle roll torque throughout the First Stage (powered) flight. This paper will provide an overview of the Ares I-X flight test process and details of the individual flight tests.

Davis, S. R.↗

NASA NTRS2010

High-Speed Ring Bus

The high-speed ring bus at the Jet Propulsion Laboratory (JPL) allows for future growth trends in spacecraft seen with future scientific missions. This innovation constitutes an enhancement of the 1393 bus as documented in the Institute of Electrical and Electronics Engineers (IEEE) 1393-1999 standard for a spaceborne fiber-optic data bus. It allows for high-bandwidth and time synchronization of all nodes on the ring. The JPL ring bus allows for interconnection of active units with autonomous operation and increased fault handling at high bandwidths. It minimizes the flight software interface with an intelligent physical layer design that has few states to manage as well as simplified testability. The design will soon be documented in the AS-1393 standard (Serial Hi-Rel Ring Network for Aerospace Applications). The framework is designed for "Class A" spacecraft operation and provides redundant data paths. It is based on "fault containment regions" and "redundant functional regions (RFR)" and has a method for allocating cables that completely supports the redundancy in spacecraft design, allowing for a complete RFR to fail. This design reduces the mass of the bus by incorporating both the Control Unit and the Data Unit in the same hardware. The standard uses ATM (asynchronous transfer mode) packets, standardized by ITU-T, ANSI, ETSI, and the ATM Forum. The IEEE-1393 standard uses the UNI form of the packet and provides no protection for the data portion of the cell. The JPL design adds optional formatting to this data portion. This design extends fault protection beyond that of the interconnect. This includes adding protection to the data portion that is contained within the Bus Interface Units (BIUs) and by adding to the signal interface between the Data Host and the JPL 1393 Ring Bus. Data transfer on the ring bus does not involve a master or initiator. Following bus protocol, any BIU may transmit data on the ring whenever it has data received from its host. There is no centralized arbitration or bus granting. The JPL design provides for autonomous synchronization of the nodes on the ring bus. An address-synchronous latency adjust buffer (LAB) has been designed that cannot get out of synchronization and needs no external input. Also, a priority-driven cable selection behavior has been programmed into each unit on the ring bus. This makes the bus able to connect itself up, according to a maximum redundancy priority system, without the need for computer intervention at startup. Switching around a failed or switched-off unit is also autonomous. The JPL bus provides a map of all the active units for the host computer to read and use for fault management. With regard to timing, this enhanced bus recognizes coordinated timing on a spacecraft as critical and addresses this with a single source of absolute and relative time, which is broadcast to all units on the bus with synchronization maintained to the tens of nanoseconds. Each BIU consists of up to five programmable triggers, which may be programmed for synchronization of events within the spacecraft of instrument. All JPL-formatted data transmitted on the ring bus are automatically time-stamped.

Wysocky, Terry↗

NASA NTRS2010

Applications of Modeling and Simulation for Flight Hardware Processing at Kennedy Space Center

The Boeing Design Visualization Group (DVG) is responsible for the creation of highly-detailed representations of both on-site facilities and flight hardware using computer-aided design (CAD) software, with a focus on the ground support equipment (GSE) used to process and prepare the hardware for space. Throughout my ten weeks at this center, I have had the opportunity to work on several projects: the modification of the Multi-Payload Processing Facility (MPPF) High Bay, weekly mapping of the Space Station Processing Facility (SSPF) floor layout, kinematics applications for the Orion Command Module (CM) hatches, and the design modification of the Ares I Upper Stage hatch for maintenance purposes. The main goal of each of these projects was to generate an authentic simulation or representation using DELMIA V5 software. This allowed for evaluation of facility layouts, support equipment placement, and greater process understanding once it was used to demonstrate future processes to customers and other partners. As such, I have had the opportunity to contribute to a skilled team working on diverse projects with a central goal of providing essential planning resources for future center operations.

Marshall, Jennifer L.↗

NASA NTRS2012

Orion Script Generator

NASA Engineering's Orion Script Generator (OSG) is a program designed to run on Exploration Flight Test One Software. The script generator creates a SuperScript file that, when run, accepts the filename for a listing of Compact Unique Identifiers (CUIs). These CUIs will correspond to different variables on the Orion spacecraft, such as the temperature of a component X, the active or inactive status of another component Y, and so on. OSG will use a linked database to retrieve the value for each CUI, such as "100 05," "True," and so on. Finally, OSG writes SuperScript code to display each of these variables before outputting the ssi file that allows recipients to view a graphical representation of Orion Flight Test One's status through these variables. This project's main challenge was creating flexible software that accepts and transfers many types of data, from Boolean (true or false) values to "Unsigned Long Long'' values (any number from 0 to 18,446,744,073,709,551,615). We also needed to allow bit manipulation for each variable, requiring us to program functions that could convert any of the multiple types of data into binary code. Throughout the project, we explored different methods to optimize the speed of working with the CUI database and long binary numbers. For example, the program handled extended binary numbers much more efficiently when we stored them as collections of Boolean values (true or false representing 1 or 0) instead of as collections of character strings or numbers. We also strove to make OSG as user-friendly and accommodating of different needs as possible its default behavior is to display a current CUI's maximum value and minimum value with three to five intermediate values in between, all in descending order. Fortunately, users can also add other input on the same lines as each CUI name to request different high values, low values, display options (ascending, sine, and so on), and interval sizes for generating intermediate values. Developing input validation took up quite a bit of time, but OSG's flexibility in the end was worth it.

Dooling, Robert J.↗

NASA NTRS2015

Spinoff 2015

Topics covered include: 3D Endoscope to Boost Safety, Cut Cost of Surgery; Audio App Brings a Better Night's Sleep Liquid Cooling Technology Increases Exercise Efficiency; Algae-Derived Dietary Ingredients Nourish Animals; Space Grant Research Launches Rehabilitation Chair; Vision Trainer Teaches Focusing Techniques at Home; Aircraft Geared Architecture Reduces Fuel Cost and Noise; Ubiquitous Supercritical Wing Design Cuts Billions in Fuel Costs; Flight Controller Software Protects Lightweight Flexible Aircraft; Cabin Pressure Monitors Notify Pilots to Save Lives; Ionospheric Mapping Software Ensures Accuracy of Pilots' GPS; Water Mapping Technology Rebuilds Lives in Arid Regions; Shock Absorbers Save Structures and Lives during Earthquakes; Software Facilitates Sharing of Water Quality Data Worldwide; Underwater Adhesives Retrofit Pipelines with Advanced Sensors; Laser Imaging Video Camera Sees through Fire, Fog, Smoke; 3D Lasers Increase Efficiency, Safety of Moving Machines; Air Revitalization System Enables Excursions to the Stratosphere; Magnetic Fluids Deliver Better Speaker Sound Quality; Bioreactor Yields Extracts for Skin Cream; Private Astronaut Training Prepares Commercial Crews of Tomorrow; Activity Monitors Help Users Get Optimum Sun Exposure; LEDs Illuminate Bulbs for Better Sleep, Wake Cycles; Charged Particles Kill Pathogens and Round Up Dust; Balance Devices Train Golfers for a Consistent Swing; Landsat Imagery Enables Global Studies of Surface Trends; Ruggedized Spectrometers Are Built for Tough Jobs; Gas Conversion Systems Reclaim Fuel for Industry; Remote Sensing Technologies Mitigate Drought; Satellite Data Inform Forecasts of Crop Growth; Probes Measure Gases for Environmental Research; Cloud Computing Technologies Facilitate Earth Research; Software Cuts Homebuilding Costs, Increases Energy Efficiency; Portable Planetariums Teach Science; Schedule Analysis Software Saves Time for Project Planners; Sound Modeling Simplifies Vehicle Noise Management; Custom 3D Printers Revolutionize Space Supply Chain; Improved Calibration Shows Images' True Colors; Micromachined Parts Advance Medicine, Astrophysics, and More; Metalworking Techniques Unlock a Unique Alloy; Low-Cost Sensors Deliver Nanometer-Accurate Measurements; Electrical Monitoring Devices Save on Time and Cost; Dry Lubricant Smooths the Way for Space Travel, Industry; and Compact Vapor Chamber Cools Critical Components.

Source record↗

NASA NTRS2017

Mars 2020 Sampling and Caching Subsystem Environmental Development Testing and Preliminary Results

The Environmental Development Testing program supported the development test efforts of the Mars 2020 Sampling and Caching Subsystem from May to November 2015. The engineering prototype Brassboard Corer was attached to a five degree-of-freedom robotic arm to execute a 96-test matrix of ambient and low pressure tests in the 10 ft. thermal vacuum chamber at the NASA Jet Propulsion Laboratory, California Institute of Technology. The Pretest, Test, and Post Test procedures are described, and some preliminary results are discussed. Data and observations from this test campaign inform the future development of the software and hardware toward the Mars 2020 flight design, including the next iteration of the rock coring drill, the Engineering Development Unit Corer.

Kriechbaum, Kristo↗

NASA NTRS2021

An Innovative Approach to Modeling VIPER Rover Software Life Cycle Cost

NASA’s “Volatiles Investigating Polar Exploration Rover” (VIPER) will be the first robotic mission to prospect for water ice near the south pole of the Moon in late 2023 on a 100-Earth-day mission. The information that the VIPER rover provides will help improve understanding of the composition, distribution, and accessibility of Lunar polar volatiles and will help determine how the Moon’s resources can support future human space exploration. VIPER, however, represents a radical departure from the way that NASA has traditionally developed planetary robotic missions. A key consequence of these differences is that estimating the cost of VIPER’s rover software is challenging and complex.For example, VIPER is being developed using management procedures typically applied to NASA research and technology projects, rather than space flight programs. In addition, key portions of the rover’s software are being designed as ground software to run on mission control computers (rather than on-board the rover as flight software as with prior planetary missions) taking advantage of continuous, interactive data communications between the Moon and Earth and higher performance computing available on the ground. Moreover, the rover’s software is being engineered using Agile software development practices and incorporates a significant amount of open-source, rather than following traditional (spiral, waterfall, etc.) development methods and in-house code. In this paper, we present an innovative process to estimate the life cycle cost of VIPER’s rover software. We first describe how we modeled the architecture and code counts for three software elements: Rover Flight Software (RFSW), Rover Ground Software (RGSW), and Rover Simulation Software (RSIM). We then discuss key challenges and unique aspects of our approach, such as the lack of Lunar rover analogies, the need to integrate and test large open source software, and the strategies developed to account for use of non-space flight management practices and the impact of the COVID-19 pandemic. We conclude with a summary of our results, including cumulative distribution, nearest neighbors and cluster analysis, as well as heuristics used to confirm the reasonableness of the cost estimate.

Utz, Hans↗

NASA NTRS1984

Applying optimization software libraries to engineering problems

Nonlinear programming, preliminary design problems, performance simulation problems trajectory optimization, flight computer optimization, and linear least squares problems are among the topics covered. The nonlinear programming applications encountered in a large aerospace company are a real challenge to those who provide mathematical software libraries and consultation services. Typical applications include preliminary design studies, data fitting and filtering, jet engine simulations, control system analysis, and trajectory optimization and optimal control. Problem sizes range from single-variable unconstrained minimization to constrained problems with highly nonlinear functions and hundreds of variables. Most of the applications can be posed as nonlinearly constrained minimization problems. Highly complex optimization problems with many variables were formulated in the early days of computing. At the time, many problems had to be reformulated or bypassed entirely, and solution methods often relied on problem-specific strategies. Problems with more than ten variables usually went unsolved.

Healy, M. J.↗

NASA NTRS2020

Evolution of the Preliminary Fault Management Architecture and Design for the Psyche Mission

The Psyche Mission presents the first opportunity toexplore the largest metal asteroid in the solar system, (16)Psyche, which is believed to be the exposed core of a largerplanetesimal that was stripped of its rocky mantle throughmultiple collisions during early solar system formation. Themission was selected in January 2017 for a 2022 launch as partof NASA’s Discovery Program and is uniquely enabled by theintegration of a Solar Electric Propulsion (SEP) Chassisdelivered by Maxar Space Solutions with JPL’s core deepspace avionics, flight software, and fault managementarchitectures. One of the key design tasks is the development ofa fault management system capable of being responsive to theunique elements of the combined JPL and Maxar spacecraftarchitecture. This new design leverages the strengths of eachorganization, with Maxar delivering its well-proven highvoltage power bus and low-thrust electric propulsionsubsystem from its GEO communications satellite product line,and JPL delivering its deep space mission expertise and thehardware and software most critical to deep space missiondesign. The development of a robust low-thrust mission andthe integration of design philosophies and hardware from twoorganizations is not without its challenges though.A key challenge in the development of the Psyche faultmanagement architecture and design is in the integration ofdesign philosophies and hardware from JPL and Maxar. Atthe architecture level, Maxar GEO communications satellitesare developed under the premise of highly responsive groundin the loop for the resolution of anomalies, and theimplementation takes a fail-operational approach to minimizedown time for its customers. In contrast, a deep space missionmust be able to maintain safety with long periods of groundcommunication outage. Additionally, with no time-criticalevents after launch, the Psyche spacecraft will generally failsafe in the presence of anomalous conditions; specialconsideration is being given to this approach, however, tominimize the loss of electric propulsion thrust time, which iscritical to low-thrust missions. At the hardware level, thedetailed definition of interfaces between JPL and Maxarhardware presents a unique challenge in the development andflowdown of fault management requirements, the developmentand implementation of fault monitors and responses, and thedevelopment and verification of fault containment boundaries.This paper describes the evolution of the Psyche faultmanagement architecture and design from the concept studyinto the preliminary design phase, with a focus on the uniquechallenges associated with flying GEO communicationssatellite hardware in deep space, implementing a robust lowthrust mission, and the integration of design philosophies andhardware from JPL and Maxar. Details regarding how thesechallenges are addressed in the fault management design inorder to maximize heritage, leverage the strengths of eachorganization, and minimize risk across the design are alsodiscussed.

Marsh, Danielle↗

NASA NTRS2016

The Soil Moisture Acttive Passive Mission: Fault Protection Performance and Lessons Learned

Fault protection as a discipline involves a collection of flight software logic and operational processes for detecting unacceptable anomalous behavior, responding prior to reaching criticality, restricting the propagation of a failure beyond a fault containment region, and recovering the vehicle back to full or degraded functionality if possible. The System Fault Protection (SFP) design for the SMAP Earth orbiter was put to the test during its 90-day vehicle commissioning activities. During this time, the SFP software autonomously protected the vehicle from multiple faults to critical hardware, and the operations team successfully returned the observatory to its science state. The SFP also performed well in the presence of anomalous behavior below true safety limits by not taking unnecessary response actions, instead allowing the operations team time to monitor the behavior. Certain aspects of the SFP design were modified during operations via both parameter updates and a full flight software update in order to better match the vehicle behavior in the flight environment. An evaluation of the SMAP SFP performance during vehicle Commissioning will be provided in this paper, as well as a set of lessons learned largely focused on visibility, SFP mutability in operations, responses to peripheral device faults, and Safe Mode recovery and design. By capturing some of the knowledge gained during SMAP Commissioning, it is intended that this paper provide guidance for making future System Fault Protection designs more robust and supportive of operations.

Clark, Jessica↗

NASA NTRS1988

Design of an interim space rescue ferry vehicle

This paper proposes a stop-gap nonoptimum vehicle for transferring astronauts from a tumbling stranded spacecraft to a nearby rescue spacecraft. The design is limited to the use of available or 'soon-to-be' available flight-qualified hardware and consists of three major components: the manned maneuvering unit, the personnel rescue enclosure, and the apogee kick motor capture device. The apogee kick motor capture device is modified to serve as the connection between the manned maneuvering unit and the personnel rescue enclosure. The performance of this interim rescue vehicle is analyzed with NASA flight simulation software to test the feasibility of the design. Results show that the control system of the manned maneuvering unit adequately limits uncommanded rotations during all simulated maneuvers in the primary control mode but not during transverse translations in the backup control mode. Impingement of thruster plumes on the personnel rescue enclosure is shown to be of some importance in certain maneuvers. The satellite stabilization mode of the control system is found to have significant rotational-to-translational coupling that has associated adverse effects on flying qualities, making the mode undesirable for the rescue mission.

Halsell, James D., Jr.↗

NASA NTRS1982

Development of flying qualities criteria for single pilot instrument flight operations

Flying qualities criteria for Single Pilot Instrument Flight Rule (SPIFR) operations were investigated. The ARA aircraft was modified and adapted for SPIFR operations. Aircraft configurations to be flight-tested were chosen and matched on the ARA in-flight simulator, implementing modern control theory algorithms. Mission planning and experimental matrix design were completed. Microprocessor software for the onboard data acquisition system was debugged and flight-tested. Flight-path reconstruction procedure and the associated FORTRAN program were developed. Algorithms associated with the statistical analysis of flight test results and the SPIFR flying qualities criteria deduction are discussed.

Bar-Gill, A.↗

NASA NTRS2021

FRESCO: A Framework for Spacecraft Systems Autonomy

Achieving the science exploration and defense goals of the following decades will require flight systems capable of operations with limited operator contact, system mode changes and retasking based on sensor data, and complex robotic operations. To support these capabilities, increasingly autonomous flight systems are required that can perform dedicated mission functions, e.g. payload targeting and communications, and system-level functions, e.g. planning and goal monitoring. Architecting an autonomous system requires a well-reasoned, self-consistent framework to avoid \textit{ad hoc} design choices that will introduce complexity and risk. The Framework for Robust Execution and Scheduling of Commands On-Board, FRESCO, is the result of lessons learned in developing a software architecture to enable autonomous solar system exploration. FRESCO generalizes this work to offer a modular, software-agnostic approach to developing verifiable architecture for autonomous space systems. FRESCO specifies guiding principles, functions, interfaces, and interactions from which mission-specific autonomous control architectures can be derived. FRESCO is a principled framework relying on explicit, state-based goal definitions, centralized management of state knowledge, clearly separated control boundaries, and hierarchical reasoning. Using components from FRESCO reference architecture, an autonomous decision-making architecture can be designed for spacecraft which can then be mapped to flight software architecture. FRESCO is flexibly defined to enable autonomous control of flight systems built using extensive software and hardware heritage. Finally, FRESCO-derived architectures support a spectrum of operator/spacecraft interactions, ranging from traditional commanding to goal-driven commanding with the ability to change mission goals autonomously. FRESCO has been used in defining the autonomy architectures for the ASTERIA mission and have been demonstrated in laboratory and software simulation for small body rendezvous and in-space servicing missions.

Kolcio, Ksenia↗

NASA NTRS1991

Getting expert systems off the ground: Lessons learned from integrating model-based diagnostics with prototype flight hardware

As an initial attempt to introduce expert system technology into an onboard environment, a model based diagnostic system using the TRW MARPLE software tool was integrated with prototype flight hardware and its corresponding control software. Because this experiment was designed primarily to test the effectiveness of the model based reasoning technique used, the expert system ran on a separate hardware platform, and interactions between the control software and the model based diagnostics were limited. While this project met its objective of showing that model based reasoning can effectively isolate failures in flight hardware, it also identified the need for an integrated development path for expert system and control software for onboard applications. In developing expert systems that are ready for flight, artificial intelligence techniques must be evaluated to determine whether they offer a real advantage onboard, identify which diagnostic functions should be performed by the expert systems and which are better left to the procedural software, and work closely with both the hardware and the software developers from the beginning of a project to produce a well designed and thoroughly integrated application.

Stephan, Amy↗

NASA NTRS2016

Modeling in the State Flow Environment to Support Launch Vehicle Verification Testing for Mission and Fault Management Algorithms in the NASA Space Launch System

Analysis methods and testing processes are essential activities in the engineering development and verification of the National Aeronautics and Space Administration's (NASA) new Space Launch System (SLS). Central to mission success is reliable verification of the Mission and Fault Management (M&FM) algorithms for the SLS launch vehicle (LV) flight software. This is particularly difficult because M&FM algorithms integrate and operate LV subsystems, which consist of diverse forms of hardware and software themselves, with equally diverse integration from the engineering disciplines of LV subsystems. M&FM operation of SLS requires a changing mix of LV automation. During pre-launch the LV is primarily operated by the Kennedy Space Center (KSC) Ground Systems Development and Operations (GSDO) organization with some LV automation of time-critical functions, and much more autonomous LV operations during ascent that have crucial interactions with the Orion crew capsule, its astronauts, and with mission controllers at the Johnson Space Center. M&FM algorithms must perform all nominal mission commanding via the flight computer to control LV states from pre-launch through disposal and also address failure conditions by initiating autonomous or commanded aborts (crew capsule escape from the failing LV), redundancy management of failing subsystems and components, and safing actions to reduce or prevent threats to ground systems and crew. To address the criticality of the verification testing of these algorithms, the NASA M&FM team has utilized the State Flow environment6 (SFE) with its existing Vehicle Management End-to-End Testbed (VMET) platform which also hosts vendor-supplied physics-based LV subsystem models. The human-derived M&FM algorithms are designed and vetted in Integrated Development Teams composed of design and development disciplines such as Systems Engineering, Flight Software (FSW), Safety and Mission Assurance (S&MA) and major subsystems and vehicle elements such as Main Propulsion Systems (MPS), boosters, avionics, Guidance, Navigation, and Control (GN&C), Thrust Vector Control (TVC), liquid engines, and the astronaut crew office. Since the algorithms are realized using model-based engineering (MBE) methods from a hybrid of the Unified Modeling Language (UML) and Systems Modeling Language (SysML), SFE methods are a natural fit to provide an in depth analysis of the interactive behavior of these algorithms with the SLS LV subsystem models. For this, the M&FM algorithms and the SLS LV subsystem models are modeled using constructs provided by Matlab which also enables modeling of the accompanying interfaces providing greater flexibility for integrated testing and analysis, which helps forecast expected behavior in forward VMET integrated testing activities. In VMET, the M&FM algorithms are prototyped and implemented using the same C++ programming language and similar state machine architectural concepts used by the FSW group. Due to the interactive complexity of the algorithms, VMET testing thus far has verified all the individual M&FM subsystem algorithms with select subsystem vendor models but is steadily progressing to assessing the interactive behavior of these algorithms with LV subsystems, as represented by subsystem models. The novel SFE applications has proven to be useful for quick look analysis into early integrated system behavior and assessment of the M&FM algorithms with the modeled LV subsystems. This early MBE analysis generates vital insight into the integrated system behaviors, algorithm sensitivities, design issues, and has aided in the debugging of the M&FM algorithms well before full testing can begin in more expensive, higher fidelity but more arduous environments such as VMET, FSW testing, and the Systems Integration Lab7 (SIL). SFE has exhibited both expected and unexpected behaviors in nominal and off nominal test cases prior to full VMET testing. In many findings, these behavioral characteristics were used to correct the M&FM algorithms, enable better test coverage, and develop more effective test cases for each of the LV subsystems. This has improved the fidelity of testing and planning for the next generation of M&FM algorithms as the SLS program evolves from non-crewed to crewed flight, impacting subsystem configurations and the M&FM algorithms that control them. SFE analysis has improved robustness and reliability of the M&FM algorithms by revealing implementation errors and documentation inconsistencies. It is also improving planning efficiency for future VMET testing of the M&FM algorithms hosted in the LV flight computers, further reducing risk for the SLS launch infrastructure, the SLS LV, and most importantly the crew.

Trevino, Luis↗

NASA NTRS2007

System Engineering Strategy for Distributed Multi-Purpose Simulation Architectures

This paper describes the system engineering approach used to develop distributed multi-purpose simulations. The multi-purpose simulation architecture focuses on user needs, operations, flexibility, cost and maintenance. This approach was used to develop an International Space Station (ISS) simulator, which is called the International Space Station Integrated Simulation (ISIS)1. The ISIS runs unmodified ISS flight software, system models, and the astronaut command and control interface in an open system design that allows for rapid integration of multiple ISS models. The initial intent of ISIS was to provide a distributed system that allows access to ISS flight software and models for the creation, test, and validation of crew and ground controller procedures. This capability reduces the cost and scheduling issues associated with utilizing standalone simulators in fixed locations, and facilitates discovering unknowns and errors earlier in the development lifecycle. Since its inception, the flexible architecture of the ISIS has allowed its purpose to evolve to include ground operator system and display training, flight software modification testing, and as a realistic test bed for Exploration automation technology research and development.

Bhula, Dlilpkumar↗

NASA NTRS1989

A knowledge-based system design/information tool for aircraft flight control systems

Research aircraft have become increasingly dependent on advanced control systems to accomplish program goals. These aircraft are integrating multiple disciplines to improve performance and satisfy research objectives. This integration is being accomplished through electronic control systems. Because of the number of systems involved and the variety of engineering disciplines, systems design methods and information management have become essential to program success. The primary objective of the system design/information tool for aircraft flight control system is to help transfer flight control system design knowledge to the flight test community. By providing all of the design information and covering multiple disciplines in a structured, graphical manner, flight control systems can more easily be understood by the test engineers. This will provide the engineers with the information needed to thoroughly ground test the system and thereby reduce the likelihood of serious design errors surfacing in flight. The secondary objective is to apply structured design techniques to all of the design domains. By using the techniques in the top level system design down through the detailed hardware and software designs, it is hoped that fewer design anomalies will result. The flight test experiences of three highly complex, integrated aircraft programs are reviewed: the X-29 forward-swept wing, the advanced fighter technology integration (AFTI) F-16, and the highly maneuverable aircraft technology (HiMAT) program. Significant operating anomalies and the design errors which cause them, are examined to help identify what functions a system design/information tool should provide to assist designers in avoiding errors.

Mackall, Dale A.↗