Search NASA⌕ Search

SEARCH · Search NASA

Results for “spacecraft data interfaces”

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 127 records · Page 7
All sourcesNASA NTRSDOE OSTI
NASA NTRS2003

Enhancing DSN Operations Efficiency with the Discrepancy Reporting Management System (DRMS)

The DRMS is the Discrepancy Reporting Management System used by the Deep Space Network (DSN). It uses a web interface and is a management tool designed to track and manage: data outage incidents during spacecraft tracks against equipment and software known as DRs (discrepancy Reports), to record "out of pass" incident logs against equipment and software in a Station Log, to record instances where equipment has be restarted or reset as Reset records, and to electronically record equipment readiness status across the DSN. Tracking and managing these items increases DSN operational efficiency by providing: the ability to establish the operational history of equipment items, data on the quality of service provided to the DSN customers, the ability to measure service performance, early insight into processes, procedures and interfaces that may need updating or changing, and the capability to trace a data outage to a software or hardware change. The items listed above help the DSN to focus resources on areas of most need.

Discrepancy Reporting Management Systems (DRMS)↗
NASA NTRS2013

Multi-User Space Link Extension (SLE) System

The Multi-User Space (MUS) Link Extension system, a software and data system, provides Space Link Extension (SLE) users with three space data transfer services in timely, complete, and offline modes as applicable according to standards defined by the Consultative Committee for Space Data Systems (CCSDS). MUS radically reduces the schedule, cost, and risk of implementing a new SLE user system, minimizes operating costs with a lights-out approach to SLE, and is designed to require no sustaining engineering expense during its lifetime unless changes in the CCSDS SLE standards, combined with new provider implementations, force changes. No software modification to MUS needs to be made to support a new mission. Any systems engineer with Linux experience can begin testing SLE user service instances with MUS starting from a personal computer (PC) within five days. For flight operators, MUS provides a familiar-looking Web page for entering SLE configuration data received from SLE. Operators can also use the Web page to back up a space mission's entire set of up to approximately 500 SLE service instances in less than five seconds, or to restore or transfer from another system the same amount of data from a MUS backup file in about the same amount of time. Missions operate each MUS SLE service instance independently by sending it MUS directives, which are legible, plain ASCII strings. MUS directives are usually (but not necessarily) sent through a TCP-IP (Transmission Control Protocol Internet Protocol) socket from a MOC (Mission Operations Center) or POCC (Payload Operations Control Center) system, under scripted control, during "lights-out" spacecraft operation. MUS permits the flight operations team to configure independently each of its data interfaces; not only commands and telemetry, but also MUS status messages to the MOC. Interfaces can use single- or multiple-client TCP/IP server sockets, TCP/IP client sockets, temporary disk files, the system log, or standard in, standard out, or standard error as applicable. By defining MUS templates in ASCII, the flight operations team can include any MUS system variable in telemetry or command headers or footers, and/or in status messages. Data fields can be arranged within messages in different sequences, according to the mission s needs. The only constraints imposed are on the format of MUS directive strings, and some bare minimum logical requirements that must be met in order for MUS to read the mission control center's spacecraft command inputs. The MUS system imposes no limits or constraints on the numbers and combinations of missions and SLE service instances that it will support simultaneously. At any time, flight operators may add, change, delete, bind, connect, or disconnect.

Perkins, Toby↗
NASA NTRS1977

Heat capacity mapping radiometer for AEM spacecraft

The operation, maintenance, and integration of the applications explorer mission heat capacity mapping radiometer is illustrated in block diagrams and detail schematics of circuit functions. Data format and logic timing diagrams are included along with radiometric and electronic calibration data. Mechanical and electrical configuration is presented to provide interface details for integration of the HCMR instrument to AEM spacecraft.

Sonnek, G. E.↗
NASA NTRS2011

Solar Dynamics Observatory Guidance, Navigation, and Control System Overview

The Solar Dynamics Observatory (SDO) was designed and built at the Goddard Space Flight Center, launched from Cape Canaveral on February 11, 2010, and reached its final geosynchronous science orbit on March 16, 2010. The purpose of SDO is to observe the Sun and continuously relay data to a dedicated ground station. SDO remains Sun-pointing throughout most of its mission for the instruments to take measurements of the Sun. The SDO attitude control system (ACS) is a single-fault tolerant design. Its fully redundant attitude sensor complement includes sixteen coarse Sun sensors (CSSs), a digital Sun sensor (DSS), three two-axis inertial reference units (IRUs), and two star trackers (STs). The ACS also makes use of the four guide telescopes included as a part of one of the science instruments. Attitude actuation is performed using four reaction wheels assemblies (RWAs) and eight thrusters, with a single main engine used to provide velocity-change thrust for orbit raising. The attitude control software has five nominal control modes, three wheel-based modes and two thruster-based modes. A wheel-based Safehold running in the attitude control electronics box improves the robustness of the system as a whole. All six modes are designed on the same basic proportional-integral-derivative attitude error structure, with more robust modes setting their integral gains to zero. This paper details the final overall design of the SDO guidance, navigation, and control (GN&C) system and how it was used in practice during SDO launch, commissioning, and nominal operations. This overview will include the ACS control modes, attitude determination and sensor calibration, the high gain antenna (HGA) calibration, and jitter mitigation operation. The Solar Dynamics Observatory mission is part of the NASA Living With a Star program, which seeks to understand the changing Sun and its effects on the Solar System, life, and society. To this end, the SDO spacecraft carries three Sun-observing instruments: Helioseismic and Magnetic Imager (HMI), led by Stanford University; Atmospheric Imaging Assembly (AIA), led by Lockheed Martin Space and Astrophysics Laboratory; and Extreme Ultraviolet Variability Experiment (EVE), led by the University of Colorado. The basic mission is to observe the Sun for a very high percentage of the 5-year mission (10-year goal) with long stretches of uninterrupted observations and with constant, high-data-rate transmission to a dedicated ground station to be located in White Sands, New Mexico. These goals guided the design of the spacecraft bus that will carry and service the three-instrument payload. Overarching design goals for the bus are geosynchronous orbit, near-constant Sun observations with the ability to fly through eclipses, and constant HGA contact with the dedicated ground station. A three-axis stabilized ACS is needed both to point at the Sun accurately and to keep the roll about the Sun vector correctly positioned with respect to the solar north pole. This roll control is especially important for the magnetic field imaging of HM I. The mission requirements have several general impacts on the ACS design. Both the AIA and HMI instruments are very sensitive to the blurring caused by jitter. Each has an image stabilization system (ISS) with some ability to filter out high frequency motion, but below the bandwidth of the ISS the control system must compensate for disturbances within the ACS bandwidth or avoid exciting jitter at higher frequencies. Within the ACS bandwidth, the control requirement imposed by AIA is to place the center of the solar disk no more than 2 arc sec, 3 , from a body-defined target based on one of the GTs that accompany the instrument. This body-defined target, called the science reference boresight (SRB), was determined from the postlaunch orientation of the GTs by averaging the bounding telescope boresights for pitch to get a pitch SRB coordinate, and by averaging the bounding boresights for yaw toet the yaw SRB coordinate. The location of this SRB in the 0.5-deg field-of-view for each GT then becomes the central target for each telescope; one GT is selected for use as the ACS controlling guide telescope (CGT) at any given time. Fine Sun-pointing is effected based on this SRB for all three instruments when the Sun is within the linear range of the CGT. In addition to limiting jitter, HMI science requires averaging several observations, making the instrument sensitive to low frequency motion that induces differential motion between each observation. This requires the spacecraft attitude to be stable about the roll axis to approximately 10 arcsec over a ten-minute period. Instrument calibrations require that the spacecraft point the SRB up to 2.5 degrees in pitch and yaw away from the center of the Sun, placing the Sun outside the field-of-view of the guide telescopes. In such instances, when the GTs cannot provide the definitive target for the ACS, on-board attitude determination combined with ephemeris prediction of the Sun direction must provide the definitive target. EVE is capable of observing the Sun with less dependence on attitude control. However, the ground data processing needs for calibrations result in the most strict attitude knowledge requirements for the mission: [35,70,70] arcsec, 3 , of knowledge with respect to the center of the solar disk. In addition to driving the ACS sensor selection, the knowledge requirements, which have their effect primarily during Inertial mode calibrations, drive the accuracy requirements for the solar ephemeris. The need to achieve and maintain geosynchronous orbit (GEO) drove the need for high-efficiency propulsive systems and appropriate attitude control. The main engine provided high specific impulse for the maneuvers to attain GEO, while the smaller ACS thrusters managed the disturbance torques of the larger engine and provided the capability for much smaller adjustment burns on orbit. SDO s large solar profile means that solar radiation pressure is a large torque disturbance, and the momentum buildup from this disturbance and the GEO altitude drives the ACS to use thrusters to manage vehicle momentum. The demanding data capture budget for the mission, however, requires SDO to avoid frequent thruster maneuvers, while concerns about on-orbit jitter restrict the maximum desired wheel speeds desired from the RWAs. The plan for on-orbit wheel speed and momentum management will be discussed as well as what is now being done in operation after the jitter environment was characterized. The SDO ACS hardware complement is single-fault tolerant. Two main processors carry virtually identical copies of the command and data handling and ACS software, and two identical attitude control electronics (ACE) boxes carry Coldfire processors with contingency ACS software and other hardware interface cards; the ACE structure allows reaction wheels to be commanded by the Sun-pointing Safehold independent of the Mil Std 1553 data bus. The sixteen Adcole CSSs are grouped into primary and backup sets of eight sensors, each set providing the ability to calculate a sun vector. Each set of eight eyes provides full 4 -steradian coverage. The Adcole DSS comprises an optics head and a separate electronics box providing a 1553 data interface. The electronics box is mounted inside the Faraday cage created by the spacecraft bus module. The DSS head with its 32- deg square FOV is mounted on the instrument module with its boresight along the spacecraft X axis, nearly aligned with the Sun during observations. Adcole has designed the DSS calibration parameters so that the accuracy is 0.24 arcminutes within 10 deg of the boresight, and diminishes to 3 arcminutes as the Sun moves towards the edges of its FOV . This DSS calibration scheme provides higher accuracy attitude determination over the range of the instrument calibration maneuvers.

Morgenstern, Wendy M.↗
NASA NTRS2012

Digital Motion Imagery, Interoperability Challenges for Space Operations

With advances in available bandwidth from spacecraft and between terrestrial control centers, digital motion imagery and video is becoming more practical as a data gathering tool for science and engineering, as well as for sharing missions with the public. The digital motion imagery and video industry has done a good job of creating standards for compression, distribution, and physical interfaces. Compressed data streams can easily be transmitted or distributed over radio frequency, internet protocol, and other data networks. All of these standards, however, can make sharing video between spacecraft and terrestrial control centers a frustrating and complicated task when different standards and protocols are used by different agencies. This paper will explore the challenges presented by the abundance of motion imagery and video standards, interfaces and protocols with suggestions for common formats that could simplify interoperability between spacecraft and ground support systems. Real-world examples from the International Space Station will be examined. The paper will also discuss recent trends in the development of new video compression algorithms, as well likely expanded use of Delay (or Disruption) Tolerant Networking nodes.

Grubbs, Rodney↗
NASA NTRSDate not supplied

Development and Validation of a High-Vacuum Thermal Conductivity Testbed for Aerospace Interface Materials

Spacecraft thermal margins depend on the temperature penalty of installed interfaces, yet catalog conductivity omits bondline thickness, mating surfaces, preload, and environment. The Testbed for Advanced Interface Materials in Vacuum (TAIMV) addresses this engineering-data gap by converting ambient/vacuum temperature fields from a four-coupon stack into quantities usable in spacecraft thermal models. Its 17-node steady-state model resolves axial conduction, parasitic fixture paths, grease-filled contact, radiation, and ambient convection. Four monolithic checks gave axial heat-rate ratios of 0.90–1.02, and Braycote calibration self-recovery gave 2.20% casewise mean absolute percentage error (MAPE) and 2.85% maximum difference. With transferable fixture terms frozen, Krytox LVP tested cross-material transfer against a manufacturer-derived external relation. The six Krytox cases gave 2.28% MAPE, 5.10% maximum difference, and full-field residual root-mean-square values of 0.553 °C ambient and 1.306 °C vacuum. Installed-joint resistance spanned 6.39–7.15 × 10⁻⁴ m²·K/W for Braycote and 4.09–4.49 × 10⁻⁴ m²·K/W for Krytox, corresponding to 2.33–6.66 K per modeled interface over the tested heat-flux range. TAIMV therefore supplies directly usable installed-joint resistance and conductance, plus apparent installed conductivity and explicitly model-conditioned grease conductivity/contact terms.

heat transfer↗
NASA NTRS2017

Dynamic Control System Mode Performance of the Space Technology-7 Disturbance Reduction System

The Space Technology-7 (ST-7) Disturbance Reduction System (DRS) is an experiment package aboard the European Space Agency (ESA) LISA Pathfinder spacecraft, launched on December 3, 2015. DRS consists of three primary components: Colloidal MicroNewton Thrusters (CMNTs), an Integrated Avionics Unit (IAU), and flight-software implementing the Command and Data Handling (C&DH) and Dynamic Control System (DCS) algorithms. The CMNTs were designed to provide thrust from 5 to 30 micro Newton, with thrust controllability and resolution of 0.1 micro Newton and thrust noise of 0.1 micro Newton/(square root of (Hz)) in the measurement band from 1-30 mHz. The IAU hosts the C&DH and DCS flight software, as well as interfaces with both the CMNT electronics and the LISA Pathfinder spacecraft. When in control, the DCS uses star tracker attitude data and capacitive or optically-measured position and attitude information from LISA Pathfinder and the LISA Technology Package (LTP) to control the attitude and position of the spacecraft and the two test masses inside the LTP. After completion of the nominal ESA LISA Pathfinder mission, the DRS experiment was commissioned followed by its nominal mission. DRS operations extended over the next five months, interspersed with station keeping, anomaly resolution, and periods where control was handed back to LISA Pathfinder for them to conduct further experiments. The primary DRS mission ended on December 6, 2016, with the experiment meeting all of its Level 1 requirements. The DCS, developed at the NASA Goddard Space Flight Center, consists of five spacecraft control modes and six test mass control modes, combined into six 'DRS Mission Modes'. Attitude Control and Zero-G were primarily used to control the spacecraft during initial handover and during many of the CMNT characterization experiments. The other Mission Modes, Drag Free Low Force, 18-DOF Transitional, and 18-DOF, were used to provide drag-free control of the spacecraft about the test masses. This paper will discuss the performance of these DCS spacecraft and test mass control modes. Flight data will be shown from each mode throughout the mission, both from nominal operations and during various flight experiments. The DCS team also made some changes to controller, filter, and limit parameters during operations; the motivation and results of these changes will be shown and discussed.

O'Donnell, James R., Jr.↗
NASA NTRS1993

Command/telemetry bus general specification for the NOAA-OPQ polar orbiting environmental satellites and EUMETSAT polar satellite systems

The document is a reference document in the Instrument Interface Description for NOAA-2000 Instruments (GSFC-S-480-53). The requirements reflect the fact that these instruments must be compatible with a number of different polar orbiting satellite vehicles including the NOAA-OPQ satellites and the EUMETSAT METOP satellites. The instrument payload will interface to the spacecraft via several standardized communication busses. The document defines the multiplex data bus conforming to the MIL-STD-1553B protocol for command and telemetry transfer between a spacecraft system and all instruments.

Source record↗
NASA NTRS1991

Guideline requirements for serviceable spacecraft grasping/berthing/docking interfaces based on simulations and flight experience

The described efforts support a NASA Space Assembly and Servicing Working Group activity to draft guideline interface standards. The general requirements are to provide a simple, reliable, and durable system. Interface requirements developed include lateral position offset, axial and lateral velocities, and angular misalignment. A survey of concepts and simulation studies of spacecraft docking, existing docking/end effector performance criteria, and space proven, qualified docking data was conducted and evaluated, in order to provide recommended mechanical interface guidelines and interface tolerances for manual and autonomous capture operations. The criterion for the selection of the guidelines was maximum capability to handle malfunctions. Originally the guidelines for a zero velocity docking were considered to be covered within the grasping/berthing definition. It is acknowledged that perhaps a separate category needs to be established for this operation. The draft standard was delivered to the AIAA for review, revision, and issuance as the first U.S. national standard guideline on interfaces. The intent is to develop the guidelines into an International Standards Organization standard.

Thompson, Allen B.↗
NASA NTRS2012

Revamping Spacecraft Operational Intelligence with Splunk

So what is Splunk? Instead of giving the technical details, which you can find online, I'll tell you what it did for me. Splunk slapped everything into one place, with one uniform format, and gave me the ability to forget about all these annoying details of where it is, how to parse it, and all that. Instead, I only need to interact with Splunk to find the data I need. This sounds simple and obvious, but it's surprising what you can do once you all of your data is indexed in one place. By having your data organized, querying becomes much easier. Let's say that I want to search telemetry for a sensor_name gtemp_1 h and to return all data that is at most five minutes old. And because Splunk can hook into a real ]time stream, this data will always be up-to-date. Extending the previous example, I can now aggregate all types of data into one view based in time. In this picture, I've got transaction logs, telemetry, and downlinked files all in one page, organized by time. Even though the raw data looks completely than this, I've defined interfaces that transform it into this uniform format. This gives me a more complete picture for the question what was the spacecraft doing at this particular time? And because querying data is simple, I can start with a big block of data and whiddle it down to what I need, rather than hunting around for the individual pieces of data that I need. When we have all the data we need, we can begin widdling down the data with Splunk's Unix-like search syntax. These three examples highlights my trial-and-error attempts to find large temperature changes. I begin by showing the first 5 temperatures, only to find that they're sorted chronologically, rather than from highest temperatures to lowest temperatures. The next line shows sorting temperatures by their values, but I find that that fs not really what I want either. I want to know the delta temperatures between readings. Looking through Splunk's user manual, I find the delta function, which lets me dynamically generate new information to use in my query. With that extra piece of information, I can now return only the telemetry readings where the temperature changed by at least 10. One other useful feature I'll mention is that all of these queries can be run through Splunk's API. So any scripting language you can think of can plug right in and make these queries. This gives us the ability to build a lot of new tools.

operational intelligence↗
NASA NTRS2002

Science opportunity analyzer - a multi-mission tool for planning

For many years the diverse scientific community that supports JPL's wide variety ofinterplanetary space missions has needed a tool in order to plan and develop their experiments. The tool needs to be easily adapted to various mission types and portable to the user community. The Science Opportunity Analyzer, SOA, now in its third year of development, is intended to meet this need. SOA is a java-based application that is designed to enable scientists to identify and analyze opportunities for science observations from spacecraft. It differs from other planning tools in that it does not require an in-depth knowledge of the spacecraft command system or operation modes to begin high level planning. Users can, however, develop increasingly detailed levels of design. SOA consists of six major functions: Opportunity Search, Visualization, Observation Design, Constraint Checking, Data Output and Communications. Opportunity Search is a GUI driven interface to existing search engines that can be used to identify times when a spacecraft is in a specific geometrical relationship with other bodies in the solar system. This function can be used for advanced mission planning as well as for making last minute adjustments to mission sequences in response to trajectory modifications. Visualization is a key aspect of SOA. The user can view observation opportunities in either a 3D representation or as a 2D map projection. The user is given extensive flexibility to customize what is displayed in the view. Observation Design allows the user to orient the spacecraft and visualize the projection of the instrument field of view for that orientation using the same views as Opportunity Search. Constraint Checking is provided to validate various geometrical and physical aspects of an observation design. The user has the ability to easily create custom rules or to use official project-generated flight rules. This capability may also allow scientists to easily impact the cost to science if flight rule changes occur. Data Output generates information based on the spacecraft's trajectory, opportunity search results or based on a created observation. The data can be viewed either in tabular format or as a graph. Finally, SOA is unique in that it is designed to be able to communicate with a variety of existing planning and sequencing tools. From the very beginning SOA was designed with the user in mind. Extensive surveys of the potential user community were conducted in order to develop the software requirements. Throughout the development period, close ties have been maintained with the science community to insure that the tool maintains its user focus. Although development is still in its early stages, SOA is already developing a user community on the Cassini project, which is depending on this tool for their science planning. There are other tools at JPL that do various pieces of what SOA can do; however, there is no other tool which combines all these functions and presents them to the user in such a convenient, cohesive, and easy to use fashion.

SOA science planning mission operations sequence s↗
NASA NTRS1984

Space Systems Technology Conference, Costa Mesa, CA, June 5-7, 1984, Technical Papers

Space station technology is considered along with a shuttle tethered satellite system development program, the development of advanced orbital maintenance/servicing techniques for EVA applications, human systems interfaces for space stations, materials and structures for space applications, progress in space nuclear reactor power systems technology development with the aid of the SP-100 Program, and the design of reliable power systems for communications satellites. Attention is given to problems and concepts of space station guidance and control, spacecraft data management hardware state-of-the-art, progressive autonomy, and automation in teleoperation from a man-machine interface viewpoint. A space exploration outlook is provided, and the space power systems of the early 21st century are discussed.

Source record↗
NASA NTRS1979

Tracking and data relay satellite system - NASA's new spacecraft data acquisition system

This paper describes NASA's new spacecraft acquisition system provided by the Tracking and Data Relay Satellite System (TDRSS). Four satellites in geostationary orbit and a ground terminal will provide complete tracking, telemetry, and command service for all of NASA's orbital satellites below a 12,000 km altitude. Western Union will lease the system, operate the ground terminal and provide operational satellite control. NASA's network control center will be the focal point for scheduling user services and controlling the interface between TDRSS and the NASA communications network, project control centers, and data processing. TDRSS single access user spacecraft data systems will be designed for time shared data relay support, and reimbursement policy and rate structure for non-NASA users are being developed.

Schneider, W. C.↗
NASA NTRS1998

An Object-Oriented Interface to the CCSDS Ground Telecommand Services

The Telecommand Data Routing and Channel Services defined by the Consultative Committee for Space Data Systems (CCSDS) are flexible enough to support a myriad of commanding models. Because the standard is so broad, the traditional approach has been to implement only the portion of the standard needed by the particular spacecraft being tested/operated. Tasked with providing Telecommand Services for an entire class of spacecraft, where each spacecraft may choose any valid CCSDS commanding model, NASA Code 584 designed a common architecture capable of handling the full CCSDS protocol. The solution uses another CCSDS standard - the Standard Formatted Data Unit (SFDU) as the interface to the Telecommand Services. SFDUs provide a consistent way of labelling data objects, as well as allowing data objects to encapsulate other data objects. The resulting interface is: - Flexible: The full Data Routing and Channel Services are available via a single interface. The client (i.e. the command source) may enter commands at any layer within the protocol stack, specify any of the data aggregation or segmentation methods, and dynamically set any configuration parameter defined in the standard. - Object-oriented: Each object specifies both the data and the actions to be performed with the data. An object may contain other objects. - Expandable: New capabilities are added by defining new objects. Objects pass thru the protocol layers until they reach the applicable layer. The resulting design is: - Modular: The logic for each protocol layer is contained in a separate Application Program Interface (API). The objects used for the external interface are also used for communication between layers. - Distributable: The design can be split along any layer boundary for distribution across multiple machines. The objects ensure data consistency across platforms. This paper describes the SFDU-based interface and the resulting protocol implementation. The implementation is currently used by NASA (National Aeronautics and Space Administration) for integration & test of the microwave Anisotropy Probe (MAP) and Earth observer-I (EO-l) spacecraft. It will be used for post-launch operations of these spacecraft as well as the Imager for Magnetopause to Aurora Global Exploration (IMAGE) spacecraft.

Ray, Timothy Joseph↗
NASA NTRS1994

Lessons learned supporting onboard solid-state recorders

With the advance of semiconductor technology, Solid-State Recorders (SSR) have matured and been accepted as primary onboard data storage devices. Their high reliability, simpler interface and control, and high flexibility have made the SSR's a superb choice in today's spacecraft design. While there are many benefits, the use of SSR's may also add significant complexity to ground data systems. For instance, real-time and playback data may be interleaved into the same data stream, making data sequencing and time ordering difficult. Stored data may be played back out of time order, increasing processing load significantly. Data may also be played back after being sorted by Virtual Channels in the SSR, potentially creating bursts in packet rates that exceed the real-time processing capabilities of the ground systems. This paper presents a summary of lessons learned through the efforts in supporting a number of NASA's missions that employ SSR's. It describes various problems encountered through the design process, and their potential impact on ground system performance, resources, and cost. Recommended approaches to minimizing the impact are demonstrated by examples. The discussion leads to the conclusion that the use of SSR's demands an even higher level of cooperation between spacecraft and ground system designers in order to build the most cost effective end-to-end system.

Shi, Jeff↗
NASA NTRS1972

Crew interface specifications preparation for in-flight maintenance and stowage functions

The findings and data products developed during the Phase 2 crew interface specification study are presented. Five new NASA general specifications were prepared: operations location coding system for crew interfaces; loose equipment and stowage management requirements; loose equipment and stowage data base information requirements; spacecraft loose equipment stowage drawing requirements; and inflight stowage management data requirements. Additional data was developed defining inflight maintenance processes and related data concepts for inflight troubleshooting, remove/repair/replace and scheduled maintenance activities. The process of maintenance task and equipment definition during spacecraft design and development was also defined and related data concepts were identified for futher development into formal NASA specifications during future follow-on study phases of the contract.

Parker, F. W.↗