SEARCH · Engineering Papers
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.
Specifications which define the system functional requirements, the subsystem and interface needs, and other requirements such as maintainability, modularity, and reliability are summarized. A design definition of all required avionics functions and a system risk analysis are presented.
On January 14, 2004, the President of the United States announced a new plan to explore space and extend a human presence across our solar system. The National Aeronautics and Space Administration (NASA) established the Exploration Systems Mission Directorate (ESMD) to develop and field a Constellation Architecture that will bring the Space Exploration vision to fruition. The Constellation Architecture includes a human-rated Crew Launch Vehicle (CLV) segment, managed by the Marshall Space Flight Center (MSFC), comprised of the First Stage (FS), Upper Stage (US), and Upper Stage Engine (USE) elements. The CLV s purpose is to provide safe and reliable crew and cargo transportation into Low Earth Orbit (LEO), as well as insertion into trans-lunar trajectories. The architecture's Spacecraft segment includes, among other elements, the Crew Exploration Vehicle (CEV), managed by the Johnson Space Flight Center (JSC), which is launched atop the CLV. MSFC is also responsible for CLV and CEV stack integration. This paper provides an overview of the Avionics and Software integration approach (which includes the Integrated System Health Management (ISHM) functions), both within the CLV, and across the CEV interface; it addresses the requirements to be met, logistics of meeting those requirements, and the roles of the various groups. The Avionics Integration and Vehicle Systems Test (ANST) Office was established at the MSFC with system engineering responsibilities for defining and developing the integrated CLV Avionics and Software system. The AIVST Office has defined two Groups, the Avionics and Software Integration Group (AVSIG), and the Integrated System Simulation and Test Integration Group (ISSTIG), and four Panels which will direct trade studies and analyses to ensure the CLV avionics and software meet CLV system and CEV interface requirements. The four panels are: 1) Avionics Integration Panel (AIP), 2) Software Integration Panel, 3) EEE Panel, and 4) Systems Simulation and Test Panel. Membership on the groups and panels includes the MSFC representatives from the requisite engineering disciplines, the First Stage, the Upper Stage, the Upper Stage Engine projects, and key personnel from other NASA centers. The four panels will take the results of trade studies and analyses and develop documentation in support of Design Analysis Cycle Reviews and ultimately the System Requirements Review.
A NASA spacesuit under the EVA Technology Domain consists of a suit system; a PLSS; and a Power, Avionics, and Software (PAS) system. Ross described the basic functions, components, and interfaces of the PLSS, which consists of oxygen, ventilation, and thermal control subsystems; electronics; and interfaces. Design challenges were reviewed from a packaging perspective. Ross also discussed the development of the PLSS over the last two decades.
Analyses of McDonnell Douglas DC-8, DC-9, and DC-10 jet transports were conducted to investigate the applicability of two segment approach noise abatement procedures to these airplanes. All models had the required glide slope capability at the certified landing flap settings. The DC-8 models would probably be limited to an upper segment glide slope of 5.5 degrees and would probably not be suitable for the two segment procedure in icing conditions. The DC-8 would not be compatible with this procedure at a reduced landing flap setting. The feasibility of installing a two segment approach system in the Douglas-built fleet of commercial jet transports from a hardware viewpoint is discussed. The candidate system consists of a two segment computer plus the necessary peripheral equipment interfaced with the existing autopilot and associated avionics. The required modifications and additions to existing equipment are described and the attendant costs estimated. Potential problems which may be encountered are also discussed.
The General Purpose Work Station (GPWS) is a laboratory multiuse facility, as demonstrated during the Spacelab Life Sciences 1 (SLS-1) flight. The unit provided particulate containment under varying conditions, served as an effective work space for manipulating live animals, e.g., rats, served as a containment facility for fixatives, and was proposed for use to conduct in-flight maintenance during connector pin repair. The cabinet has a front door large enough to allow installation of a full-size microscope in-flight and is outfitted with a side window to allow delivery of items into the cabinet without exposure to the spacelab atmosphere. Additional support subsystems include inside cabinet mounting, surgical glove fine manipulations capability, and ac or dc power supply for experiment equipment, as will be demonstrated during Spacelab J. The GPWS, integrated and maintained in a double flight-rack, interfaces to spacelab systems including water cooling, avionics and cabin air, and power. Verification has been completed for multiple spacelab scenarios including SLS-2, SL-J, and SLS-3.
NASA's Goddard Space Flight Center Shuttle Small Payloads Project (SSPP), in partnership with the United States Air Force and NASA's Explorer Program, is developing a Shuttle based launch system called SHELS (Shuttle Hitchhiker Experiment Launcher System), which shall be capable of launching up to a 400 pound spacecraft from the Shuttle cargo bay. SHELS consists of a Marman band clamp push-plate ejection system mounted to a launch structure; the launch structure is mounted to one Orbiter sidewall adapter beam. Avionics mounted to the adapter beam will interface with Orbiter electrical services and provide optional umbilical services and ejection circuitry. SHELS provides an array of manifesting possibilities to a wide range of satellites.
A document describes a high-performance, modular, and state-of-the-art Command and Data Handling (C&DH) system developed for use on the Lunar Reconnaissance Orbiter (LRO) mission. This system implements a complete hardware C&DH subsystem in a single chassis enclosure that includes a processor card, 48 Gbytes of solid-state recorder memory, data buses including MIL-STD-1553B, custom RS-422, SpaceWire, analog collection, switched power services, and interfaces to the Ka-Band and S-Band RF communications systems. The C&DH team capitalized on extensive experience with hardware and software with PCI bus design, SpaceWire networking, Actel FPGA design, digital flight design techniques, and the use of VxWorks for the real-time operating system. The resulting hardware architecture was implemented to meet the LRO mission requirements. The C&DH comprises an enclosure, a backplane, a low-voltage power converter, a single-board computer, a communications interface board, four data storage boards, a housekeeping and digital input/output board, and an analog data acquisition board. The interfaces between the C&DH and the instruments and avionics are connected through a SpaceWire network, a MIL-STD-1553 bus, and a combination of synchronous and asynchronous serial data transfers over RS-422 and LVDS (low-voltage differential-signaling) electrical interfaces. The C&DH acts as the spacecraft data system with an instrument data manager providing all software and internal bus scheduling, ingestion of science data, distribution of commands, and performing science operations in real time.
Returning samples from Low Earth Orbit (LEO) is no simple task. Whether the samples are scientific experiments or surveillance footage, engineers must overcome many challenges to achieve mission success. In August of 1960 the first payload recovered from LEO, the Corona capsule, carried “more photographic coverage of the Soviet Union than all previous U-2 missions”. The Corona program proved that re-turning surveillance footage from LEO is possible, the program is still referenced today when designing new sample return missions. Although there are many crucial subsystems that make up a sample return capsule, the avionics subsystem demands the most attention. This paper will discuss how current CubeSat avionics components can be applied to large sample return missions. One advantage of using CubeSat avionics components is that they can fit into a 1.5 U (10x10x15 cm) compartment, leaving more room for the payload. This paper is broken down as follows. First, the reader is introduced to the history of sample return projects. The major design strengths of previous projects are analyzed and applied to the current capsule design. Next, the typical trajectory of a capsule is presented along with mission requirements and operations. During the re-entry phase, the avionics subsystem is responsible for commanding the deployment of the parachute, back shell, and the heat shield. Next, the power subsystem is discussed in detail including a trade study on batteries and voltage regulators. Next, the interface between the Ground Support Equipment (GSE) and the avionics components is discussed. It is important that the capsule is able to provide avionics system state of health to ensure proper functionality before the capsule is launched. Next, an in-depth analysis of current TechEdSat avionics components, with proven flight history, are presented. The various avionics components including the radios, GPS, IMU, temperature sensors, altitude sensors, and ejectors are discussed. The application of cur-rent avionics components to a sample return projects are analyzed. After, the wiring diagram is presented along with a discussion of the design. Next, a summary of how the avionics components are tested and validated is pro-vided. Finally, this article will present current sample return missions TechEdSat avionics components are being applied to. CubeSat Avionics can be applied to almost all sample return missions due to their compact configuration and proven space flight heritage. The TechEdSat team is currently making great progress in returning samples from the International Space Station (ISS) and is excited to present how their avionics components can be applied to a full-scale sample return mission.
An extender system for MIL-STD-1553 buses transparently couples bus components at multiple developer sites. The bus network extender is a relatively inexpensive system that minimizes the time and cost of integration of avionic systems by providing a convenient mechanism for early testing without the need to transport the usual test equipment and personnel to an integration facility. This bus network extender can thus alleviate overloading of the test facility while enabling the detection of interface problems that can occur during the integration of avionic systems. With this bus extender in place, developers can correct and adjust their own hardware and software before products leave a development site. Currently resident at Johnson Space Center, the bus network extender is used to test the functionality of equipment that, although remotely located, is connected through a MILSTD- 1553 bus. Inasmuch as the standard bus protocol for avionic equipment is that of MIL-STD-1553, companies that supply MIL-STD-1553-compliant equipment to government or industry and that need long-distance communication support might benefit from this network bus extender
The Pilot-Vehicle Interface of modern aircraft is the cognitive, sensory, and psychomotor link between the pilot, the avionics modules, and all other systems on board the aircraft. To assist pilot-vehicle interface designers, a C Language Integrated Production System (CLIPS) based tool was developed that allows design information to be stored in a table that can be modified by rules representing design knowledge. Developed for the Apple Macintosh, the tool allows users without any CLIPS programming experience to form simple rules using a point and click interface.
This project focuses on the testing of the telecommunications interface subsystem of the Multi-Mission System Architecture Platform to ensure proper functionality. The Multi-Mission System Architecture Platform is a set of basic tools designed to be used in future spacecraft. The responsibilities of the telecommunications interface include communication between the spacecraft and ground teams as well as acting as the bus controller for the system. The tests completed include bit wise read\write tests to each register, testing of status bits, and verifying various bus controller activities. Testing is accomplished through the use of software-based simulations run on an electronic design of the system. The tests are written in Verilog Hardware Definition Language and they simulate specific states and conditions in telecommunication interfaces. Upon successful completion, the output is examined to verify that the system responded appropriately.
This paper presents an overview of the application of the Space Generic Open Avionics Architecture (SGOAA) to the Space Shuttle Data Processing System (DPS) architecture design. This application has been performed to validate the SGOAA, and its potential use in flight critical systems. The paper summarizes key elements of the Space Shuttle avionics architecture, data processing system requirements and software architecture as currently implemented. It then summarizes the SGOAA architecture and describes a tailoring of the SGOAA to the Space Shuttle. The SGOAA consists of a generic system architecture for the entities in spacecraft avionics, a generic processing external and internal hardware architecture, a six class model of interfaces and functional subsystem architectures for data services and operations control capabilities. It has been proposed as an avionics architecture standard with the National Aeronautics and Space Administration (NASA), through its Strategic Avionics Technology Working Group, and is being considered by the Society of Aeronautic Engineers (SAE) as an SAE Avionics Standard. This architecture was developed for the Flight Data Systems Division of JSC by the Lockheed Engineering and Sciences Company, Houston, Texas.
System architectures which incorporate fail operative flight guidance functions within a total integrated avionics complex are described. It is shown that the mixture of flight critical and nonflight critical functions within a common computer complex is an efficient solution to the integration of navigation, guidance, flight control, display, and flight management. Interfacing subsystems retain autonomous capability to avoid vulnerability to total avionics system shutdown as a result of only a few failures.
NASA has conducted dynamic tests on each of its major launch vehicles during the past 45 years. Each test has provided invaluable data to correlate and correct analytical models used to predict structural responses to differing dynamics for these vehicles. With both Saturn V and Space Shuttle, hardware changes were also required to the flight vehicles to ensure crew and vehicle safety. The Ares I IVGVT will undoubtedly provide similar valuable test data to support successful flights of the Constellation Program. The IVGVT will provide test determined natural frequencies, mode shapes and damping for the Ares I. This data will be used to support controls analysis by providing this test data to reduce uncertainty in the models. The value of this testing has been proven by past launch vehicle successes and failures. Performing dynamic testing on the Ares vehicles will provide confidence that the launch vehicles will be safe and successful in their missions. In addition, IVGVT will provide the following benefits for the Ares rockets: a) IVGVT data along with Ares development flights like Ares I-X, Ares I-Y, Ares I-X Prime, and Orion-1 or others will reduce the risk to the Orion-2 crew. IVGVT will permit anchoring the various analytical and operational models used in so many different aspects of Ares operations. b) IVGVT data will permit better understanding of the structural and GN&C margins of the spacecraft and may permit mass savings or expanded day-of-launch opportunities or fewer constraints to launch. c) Undoubtedly IVGVT will uncover some of the "unknown unknowns" so often seen in developing, launching, and flying new spacecraft vehicles and data from IVGVT may help prevent a loss of vehicle or crew. d) IVGVT also will be the first time Ares I flight-like hardware is transported, handled, rotated, mated, stacked, and integrated. e) Furthermore, handling and stacking the IVGVT launch vehicle stacks will be an opportunity to understand certain aspects of vehicle operability much better (for example, handling procedures, touch-labor time to accomplish tasks, access at interfaces, access to stage mating bolts, access to avionics boxes, access to the Interstage, GSE functionality, and many other important aspects of Ares I operability). All of these results will provide for better vehicle safety and better stewardship of national resources as NASA begins its next phase of human space exploration.
The flight software on virtually every mission currently managed by JPL has several major flaws that make it vulnerable to potentially fatal software defects. Many of these problems can be addressed by recently developed partitioned operating systems (OS). JPL has avoided adopting a partitioned operating system on its flight missions, primarily because doing so would require significant changes in flight software design, and the risks associated with changes of that magnitude cannot be accepted by an active flight project. The choice of a partitioned OS can have a dramatic effect on the overall system and software architecture, allowing for realization of benefits far beyond the concerns typically associated with the choice of OS. Specifically, we believe that a partitioned operating system, when coupled with an appropriate architecture, can provide a strong infrastructure for developing systems for which reusability, modifiability, testability, and reliability are essential qualities. By adopting a partitioned OS, projects can gain benefits throughout the entire development lifecycle, from requirements and design, all the way to implementation, testing, and operations.
With the advent of digital avionics, the workload of the pilot in a moderen transport aircraft is increasing significantly. This situation makes it necessary to reduce pilot workload with the aid of new advanced technologies. As part of an effort to improve information management systems, NASA has, therefore, studied an advanced concept for managing the navigational tasks of a modern transport aircraft. This concept is mainly concerned with the simplification of the pilot interface. The advanced navigational system provides a simple method for a pilot to enter new waypoints to change his flight plan because of heavy traffic, adverse weather conditions, or other reasons. The navigational system was implemented and evaluated in a flight simulator representative of a modern transport aircraft. Attention is given to the simulator, flight simulation, multimode devices, and the navigational system.
The paper considers STS payload-interface verification requirements and the capability provided by STS to support verification. The intent is to standardize as many interfaces as possible, not only through the design, development, test and evaluation (DDT and E) phase of the major payload carriers but also into the operational phase. The verification process is discussed in terms of its various elements, such as the Space Shuttle DDT and E (including the orbital flight test program) and the major payload carriers DDT and E (including the first flights). Five tools derived from the Space Shuttle DDT and E are available to support the verification process: mathematical (structural and thermal) models, the Shuttle Avionics Integration Laboratory, the Shuttle Manipulator Development Facility, and interface-verification equipment (cargo-integration test equipment).
The aerodynamic technology for a vertical attitude VSTOL (VATOL) supersonic fighter/attack aircraft was studied. The selected configuration features a tailless clipped delta wing with leading-edge extension (LEX), maneuvering flaps, top-side inlet, twin dry engines and vectoring nozzles. A relaxed static stability is employed in conjunction with the maneuvering flaps to optimize transonic performance and minimize supersonic trim drag. Control for subaerodynamic flight is obtained by gimballing the nozzles in combination with wing tip jets. Emphasis is placed on the development of aerodynamic characteristics and the identification of aerodynamic uncertainties. A wind tunnel test program is proposed to resolve these uncertainties and ascertain the feasibility of the conceptual design. Ship interface, flight control integration, crew station concepts, advanced weapons, avionics, and materials are discussed.