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.
The Small Explorer Data System was developed by NASA Goddard Space Flight Center using a 'standard interfaces' approach. Standard interfaces make it adaptable to a wide variety of missions. The paper describes the Small Explorer Data System with particular emphasis on the standard interfaces incorporated in both the hardware and software.
This paper will discuss data systems interface standards including the goals and benefits in their application to space flight programs. Recent trends toward increased international cooperation in space research and applications missions have resulted in a greater emphasis on compatible interface standards among the participating agencies. The discussion will highlight the Consultative Committee for Space Data Systems (CCSDS), a consortium of 19 space agencies formed in 1982 in order to provide a technical forum for developing guidelines for compatible data systems standards among cooperating space agencies worldwide. CCSDS effort is seen as contributing significantly to the objectives of the IAF's Symposium on Space Exploration.
The ability to configure data systems using modules provided by independent manufacturers is complicated by the wide range of electrical, mechanical, and functional characteristics exhibited within the equipment provided by different manufacturers of computers, peripherals, and terminal devices. A number of international organizations were and still are involved in the creation of standards that enable devices to be interconnected with minimal difficulty, usually involving only a cable or data bus connection that is defined by the standard. The elements covered by an interface standard are covered and the most prominent interface standards presently in use are identified and described.
The network operations control center standard interface has been adopted as a standard computer interface for all future minicomputer based subsystem development for the Deep Space Network. Discussed is an intercomputer communications link using a pair of coaxial cables. This unit is capable of transmitting and receiving digital information at distances up to 600 m with complete ground isolation between the communicating devices. A converter is described that allows a computer equipped with the standard interface to use the twin coaxial link.
A key contribution to surface systems sustainability on Lunar and planetary surfaces is commonality between hardware and software interfaces. Generic interfaces for data, power, and fluids will reduce risk, promote interoperability, and define standard interfaces across surface exploration projects and programs. Standardized interfaces would be advantageous for improving efficiency and reducing overall complexity, which are critical considerations for future space exploration. Furthermore, it will provide cost reductions to NASA’s Artemis program over its life cycle (in Operations & Maintenance (O&M) and Logistics). Unique proprietary interfaces if considered or allowed would not only increase complexity but also add cost to the programs. Of course, understanding what will work and not work effectively in these unique environments such as the lunar surface is important. These unique environments require much needed intelligent design, prototyping, comprehensive testing, and field experience, utilizing consensus on common interface solutions.
Factors applicable to fixed angle, large field and fixed angle, large building flat plate photovoltaic (PV) generator arrays are discussed in the context of standardization. It is concluded that structural interface standardization may be highly desirable in any one major project, but not at this time in the overall PV industry. Attempts to mandate such standardization will act as a deterrent to long-range improvements. In specific projects, structural standardization should be defined at the largest practical interface, leaving the maximum possible freedom to the module and array manufacturer. There is a corollary area, however, where detailed standards would benefit the industry; the matter of Standard Practices. Work being done towards definition of acceptable/desirable practices in materials, finishes, fastening and locking methods, grounding techniques, lightning protection, etc., and in handling the environmental ranges, should be continued.
The interfaces which shall be provided by the baseline shuttle mid-deck for payload use within the mid-deck area are defined, as well as all constraints which shall be observed by all the users of the defined interfaces. Commonality was established with respect to analytical approaches, analytical models, technical data and definitions for integrated analyses by all the interfacing parties. Any payload interfaces that are out of scope with the standard interfaces defined shall be defined in a Payload Unique Interface Control Document (ICD) for a given payload. Each Payload Unique ICD will have comparable paragraphs to this ICD and will have a corresponding notation of A, for applicable; N/A, for not applicable; N, for note added for explanation; and E, for exception. On any flight, the STS reserves the right to assign locations to both payloads mounted on an adapter plate(s) and payloads stored within standard lockers. Specific locations requests and/or requirements exceeding standard mid-deck payload requirements may result in a reduction in manifesting opportunities.
The DSN Standard Interface Adapter and Buffer Assembly (referred to as the 900/SIA) is used to effect interface compatibility between the Xerox data systems 920 computer (XDS 920) and the Mark 3 data system (MDS) processors. It sets forth the requirements based on the differences between the two systems. Operational characteristics and general design strategy are described, as well as certain efficient implementation techniques used. From a software standpoint, the transfer protocol is discussed to a level of detail sufficient for its operation.
A method of applying open-operating-system standard interfaces to the NASA User Interface Language (UIL) has been devised. UIL is a computing language that can be used in monitoring and controlling automated processes: for example, the Timeliner computer program, written in UIL, is a general-purpose software system for monitoring and controlling sequences of automated tasks in a target system. In providing the major elements of connectivity between UIL and the target system, the present method offers advantages over the prior method. Most notably, unlike in the prior method, the software description of the target system can be made independent of the applicable compiler software and need not be linked to the applicable executable compiler image. Also unlike in the prior method, it is not necessary to recompile the source code and relink the source code to a new executable compiler image. Abstraction of the description of the target system to a data file can be defined easily, with intuitive syntax, and knowledge of the source-code language is not needed for the definition.
Explore the source record for details and available documents.
Explore the source record for details and available documents.
Forward-looking windshear systems are developing to a point (particularly the infrared sensors) where their interface with the cockpit and reactive windshear systems needs to be defined. As airlines retrofit their aircraft with reactive windshear systems, it is important to recognize that onboard windshear systems of the future will be a combination of both forward-looking and reactive elements. Today's reactive systems need to be built with the capability to interface with the forward-looking systems of tomorrow. This presentation is a first step at looking at the requirements and defining interface standards for integrated forward-looking and reactive windshear systems. Undoubtedly the requirements for interfacing these types of windshear systems will change as the technology changes.
The American Institute of Aeronautics and Astronautics (AIAA) has undertaken an important standards initiative in the area of spacecraft guidance, navigation, and control (GN&C) subsystem interfaces. The objective of this effort is to establish standards that will promote interchangeability of major GN&C components, thus enabling substantially lower spacecraft development costs. Although initiated by developers of conventional spacecraft GN&C, it is anticipated that interface standards will also be of value in reducing the development costs of micro-engineered spacecraft. The standardization targets are specifically limited to interfaces only, including information (i.e. data and signal), power, mechanical, thermal, and environmental interfaces between various GN&C components and between GN&C subsystems and other subsystems. The current emphasis is on information interfaces between various hardware elements (e.g., between star trackers and flight computers). The poster presentation will briefly describe the program, including the mechanics and schedule, and will publicize the technical products as they exist at the time of the conference. In particular, the rationale for the adoption of the AS1773 fiber-optic serial data bus and the status of data interface standards at the application layer will be presented.
Space exploration on planetary surfaces will require the use of various surface systems which will likely need to interface with one another. These systems must communicate and share data, as well as distribute power and transfer fluids for sustainable surface operations. Such systems can range from landers, surface habitats, mobility systems, cargo, and In-Situ Resource Utilizations (ISRUs). Previous and current programs have developed space interoperability standards that help aid in reducing potential risks of interface integration. One example of this is the International Deep Space Interoperability Standards (IDSIS) which focuses on deep space exploration. A goal of the Artemis program is to develop a sustained human presence on the lunar surface that would be a training ground for future Mars exploration. Therefore, it will be beneficial to identify interface standards between the surface assets which will help mitigate risk and reduce complexity in the harsh environments of space exploration. A key contribution to sustainability is commonality between hardware and software interfaces. Generic interfaces for data, power, and fluids will reduce risk, promote interoperability, and define standard interfaces across surface exploration projects and programs. Standardized interfaces would be advantageous for improving efficiency and reducing overall complexity, which are critical considerations for future space exploration. Furthermore, it will provide cost reductions to the Artemis programs over their life cycle (in Operations & Maintenance (O&M) and Logistics). Unique proprietary interfaces if considered or allowed would not only increase complexity but also add cost to the programs. Of course, understanding what will work and not work effectively in these unique environments such as the lunar surface is important. These unique environments require much needed intelligent design, prototyping, comprehensive testing, and field experience, utilizing consensus on common interface solutions.
NASA's traditional science data processing systems have focused on specific missions, and providing data access, processing and services to the funded science teams of those specific missions. Recently NASA has been modifying this stance, changing the focus from Missions to Measurements. Where a specific Mission has a discrete beginning and end, the Measurement considers long term data continuity across multiple missions. Total Column Ozone, a critical measurement of atmospheric composition, has been monitored for'decades on a series of Total Ozone Mapping Spectrometer (TOMS) instruments. Some important European missions also monitor ozone, including the Global Ozone Monitoring Experiment (GOME) and SCIAMACHY. With the U.S.IEuropean cooperative launch of the Dutch Ozone Monitoring Instrument (OMI) on NASA Aura satellite, and the GOME-2 instrumental on MetOp, the ozone monitoring record has been further extended. In conjunction with the U.S. Department of Defense (DoD) and the National Oceanic and Atmospheric Administration (NOAA), NASA is now preparing to evaluate data and algorithms for the next generation Ozone Mapping and Profiler Suite (OMPS) which will launch on the National Polar-orbiting Operational Environmental Satellite System (NPOESS) Preparatory Project (NPP) in 2010. NASA is constructing the Science Data Segment (SDS) which is comprised of several elements to evaluate the various NPP data products and algorithms. The NPP SDS Ozone Product Evaluation and Test Element (PEATE) will build on the heritage of the TOMS and OM1 mission based processing systems. The overall measurement based system that will encompass these efforts is the Atmospheric Composition Processing System (ACPS). We have extended the system to include access to publically available data sets from other instruments where feasible, including non-NASA missions as appropriate. The heritage system was largely monolithic providing a very controlled processing flow from data.ingest of satellite data to the ultimate archive of specific operational data products. The ACPS allows more open access with standard protocols including HTTP, SOAPIXML, RSS and various REST incarnations. External entities can be granted access to various modules within the system, including an extended data archive, metadata searching, production planning and processing. Data access is provided with very fine grained access control. It is possible to easily designate certain datasets as being available to the public, or restricted to groups of researchers, or limited strictly to the originator. This can be used, for example, to release one's best validated data to the public, but restrict the "new version" of data processed with a new, unproven algorithm until it is ready. Similarly, the system can provide access to algorithms, both as modifiable source code (where possible) and fully integrated executable Algorithm Plugin Packages (APPs). This enables researchers to download publically released versions of the processing algorithms and easily reproduce the processing remotely, while interacting with the ACPS. The algorithms can be modified allowing better experimentation and rapid improvement. The modified algorithms can be easily integrated back into the production system for large scale bulk processing to evaluate improvements. The system includes complete provenance tracking of algorithms, data and the entire processing environment. The origin of any data or algorithms is recorded and the entire history of the processing chains are stored such that a researcher can understand the entire data flow. Provenance is captured in a form suitable for the system to guarantee scientific reproducability of any data product it distributes even in cases where the physical data products themselves have been deleted due to space constraints. We are currently working on Semantic Web ontologies for representing the various provenance information. A new web site focusing on consolidating informaon about the measurement, processing system, and data access has been established to encourage interaction with the overall scientific community. We will describe the system, its data processing capabilities, and the methods the community can use to interact with the standard interfaces of the system.
The Consultative Committee for Space Data Systems (CCSDS) is an international organization of national space agencies (such as NASA in the United States) that is organized to promote the interchange of space related information. Now, CCSDS is branching out to provide new standards for the interchange of information, and the interconnection of subsystems and devices onboard of a spacecraft. This effort is know as Spacecraft Onboard Interface (SOIF). SOIF will publish standards that will allow for the enhanced reuse of spacecraft equipment and software. SOIF expects that these standards will be well known and used within the space community, and that they will be based on or similar to the well-known Internet protocols. This paper will provide a description of the SOIF work by reviewing this work with three orthogonal views. The first of these views is the Protocol view, which describes the protocols and services that are to be implemented in order to provide the users with the advantages of the SOIF architecture. The second of these views is the Services View, which describes the data communications services that are provided to the users. And finally, the Interoperability view provides a description to users how SOIF can be used to interchange between different spacecraft data busses. This paper will give the reader an excellent introduction to the work of the international SOIF team.
The Consultative Committee for Space Data Systems (CCSDS) is an international organization of national space agencies (such as NASA in the United States) that is organized to promote the interchange of space related information. Now, CCSDS is branching out to provide new standards for the interchange of information, and the interconnection of subsystems and devices onboard of a spacecraft. This effort is know as Spacecraft Onboard Interface (SOIF). SOIF will publish standards that will allow for the enhanced reuse of spacecraft equipment and software. SOIF expects that these standards will be well known and used within the space community, and that they will be based on or similar to the well-known Internet protocols. This paper will provide a description of the SOIF work by reviewing this work with three orthogonal views. The first of these views is the Protocol view, which describes the protocols and services that are to be implemented in order to provide the users with the advantages of the SOIF architecture. The second of these views is the Services View, which describes the data communications services that are provided to the users. And finally, the Interoperability view provides a description to users how SOIF can be used to interchange between different spacecraft data busses. This paper will give the reader an excellent introduction to the work of the international SOIF team.
The purpose of the NASA Space Assembly and Servicing Working Group (SASWG) is to study enabling technologies for on-orbit spacecraft maintenance and servicing. One key technology required for effective space logistics activity is the development of standard spacecraft interfaces, including the 'Basic Set' defined by NASA, the U.S. Space Command, and industry panelists to be the following: (1) navigation aids; (2) grasping, berthing, and docking; and (3) utility connections for power, data, and fluids. Draft standards have been prepared and referred to professional standards organizations, including the AIAA, EIA, and SAE space standards committee. The objective of the SASWG is to support these committees with the technical expertise required to prepare standards, guidelines, and recommended practices which will be accepted by the ANSI and international standards organizations, including the ISO, IEC, and PASC.