Search NASA⌕ Search

SEARCH · Search NASA

Results for “standard user interface”

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 199 records · Page 11
All sourcesNASA NTRSDOE OSTI
NASA NTRS2006

SpaceWire Protocol ID: What Does It Mean To You?

Spacewire is becoming a popular solution for satellite high-speed data buses because it is a simple standard that provides great flexibility for a wide range of system requirements. It is simple in packet format and protocol, allowing users to easily tailor their implementation for their specific application. Some of the attractive aspects of Spacewire that make it easy to implement also make it hard for future reuse. Protocol reuse is difficult because Spacewire does not have a defined mechanism to communicate with the higher layers of the protocol stack. This has forced users of Spacewire to define unique packet formats and define how these packets are to be processed. Each mission writes their own Interface Control Document (ICD) and tailors Spacewire for their specific requirements making reuse difficult. Part of the reason for this habit may be because engineers typically optimize designs for their own requirements in the absence of a standard. This is an inefficient use of project resources and costs more to develop missions. A new packet format for Spacewire has been defined as a solution for this problem. This new packet format is a compliment to the Spacewire standard that will support protocol development upon Spacewire. The new packet definition does not replace the current packet structure, i.e., does not make the standard obsolete, but merely extends the standard for those who want to develop protocols over Spacewire. The Spacewire packet is defined with the first part being the Destination Address, which may be one or more bytes. This is followed by the packet cargo, which is user defined. The cargo is truncated with an End-Of-Packet (EOP) marker. This packet structure offers low packet overhead and allows the user to define how the contents are to be formatted. It also provides for many different addressing schemes, which provide flexibility in the system. This packet flexibility is typically an attractive part of the Spacewire. The new extended packet format adds one new field to the packet that greatly enhances the capability of Spacewire. This new field called the Protocol Identifier (ID) is used to identify the packet contents and the associated processing for the packet. This feature along with the restriction in the packet format that uses the Protocol ID, allows a deterministic method of decoding packets that was not before possible. The first part of the packet is still the Destination Address, which still conforms to the original standard but with one restriction. The restriction is that the first byte seen at the destination by the user needs to be a logical address, independent of the addressing scheme used. The second field is defined as the Protocol ID, which is usually one byte in length. The packet cargo (user defined) follows the Protocol ID. After the packet cargo is the EOP, which defines the end of packet. The value of the Protocol ID is assigned by the Spacewire working group and the protocol description published for others to use. The development of Protocols for Spacewire is currently the area of greatest activity by the Spacewire working group. The first protocol definition by the working group has been completed and is now in the process of formal standardization. There are many other protocols in development for missions that have not yet received formal Protocol ID assignment, but even if the protocols are not formally assigned a value, this effort will provide synergism for future developments.

Rakow, Glenn↗
NASA NTRSDate not supplied

NASA's Efforts to Commercialize Communications Services for Mission in Near-Earth Space

The National Aeronautics and Space Administration (NASA) Space Communications and Navigation (SCaN)Program enables high speed, robust, secure and cost-effective space communications and navigation services to current and future science and exploration missions. Consistent with National Space Policy, NASA is pursuing the use of demonstrated commercial services for all its future near-Earth requirements through a flexible, multi-provider approach that minimizes risks to the user missions and ensures costs to user missions are reasonable. Progress toward this goal is advancing in multiple key areas including direct to Earth (DTE), space-based relay, technology investments, required spectrum regulatory changes and mission engagement and infusion. The transition to commercial DTE services is already underway, with a target for transition by 2024. The primary functions to execute SCaN’s DTE strategy include increasing commercial service allocations by leveraging current commercial network providers and enabling seamless onboarding of additional providers into the network. Furthermore, moving away from government DTE services will allow operational costs to be optimized. A more gradual approach is planned for the transition to commercial space-based relay services to allow for demonstration and operationalization of commercial services for future users by 2030. In June of 2022, six American SATCOM vendors were awarded a combined $278.5 million through Funded Space Act Agreements (FSAAs) for the first cycle of demonstration and validation activities. The end-to-end service capabilities being targeted are based on existing NASA mission operational needs. Accordingly, each company has proposed a technical approach to lower costs, increase flexibility, and improve performance for a broad range of missions. Successful user mission transition to commercial services, both DTE and space-based relay, are dependent on the technologies and capabilities that address gaps in commercial capability. NASA is investing in technology development and pursuing a new strategic approach to the creation or adoption of space communications standards to move the agency toward a commercial paradigm. Wideband and multi-lingual user terminals are being developed to bridge differences in industry services. Building on ground demonstrations completed in 2021, the Johns Hopkins Applied Physics Lab (APL) will be flight testing a multi-lingual wideband terminal (payload) and demonstrating connectivity to both government and commercial relay services. NASA holds a leadership role in multiple civil space standards bodies and international coordination groups to ensure that standards supporting interoperability are developed with defined functions, interfaces, and performance. However, to successfully meet commercialization objectives, NASA seeks to collaborate with industry, and as applicable adopt or adapt to commercially defined standards. As such, NASA joined the 3rd Generation Partnership Project (3GPP) as an official member in 2021 to advocate for the inclusion of space missions as a unique user segment in future 5G non-terrestrial networks, and to better understand the scope of 3GPP releases and implications for space users. Further, engagement in Spectrum regulatory bodies is being undertaken to augment existing space-Earth and inter-satellite frequency allocations available for both government and commercial space systems. This paper addresses the recent progress toward NASA’s commercial space communications transition objectives and how key challenges are being navigated.

Gregory W Heckler↗
NASA NTRS1986

Investigation of local area networks for an obiting space station

An investigation and test of various equipment was conducted to determine its state of repair and suitability for use in a test-bed computer network (to be used to simulate a space station configuration of computers for control and monitoring). A research study was also made of various network types, including the IEEE network standards: (1) Carrier Sense Multiple Access with Collision Detection. (2) Token Passing Bus (3) Token Passing Ring, and (4) the draft ANSI standard for a High Speed Local Network, CSMA with Collision Avoidance. No firm conclusions are possible at this time as to which would be most suitable. An evaluation of the user interface of a space station database program, FREDSS (Formatted Retrieval and Entry of Data for Space Station, preliminary version), was also conducted and recommendations were made for possible improvements.

Deacetis, L. A.↗
NASA NTRS1989

CHIMERA II - A real-time multiprocessing environment for sensor-based robot control

A multiprocessing environment for a wide variety of sensor-based robot system, providing the flexibility, performance, and UNIX-compatible interface needed for fast development of real-time code is addressed. The requirements imposed on the design of a programming environment for sensor-based robotic control is outlined. The details of the current hardware configuration are presented, along with the details of the CHIMERA II software. Emphasis is placed on the kernel, low-level interboard communication, user interface, extended file system, user-definable and dynamically selectable real-time schedulers, remote process synchronization, and generalized interprocess communication. A possible implementation of a hierarchical control model, the NASA/NBS standard reference model for telerobot control system is demonstrated.

Stewart, David B.↗
NASA NTRS1992

Data Management Systems (DMS): Complex data types study. Volume 1: Appendices A-B. Volume 2: Appendices C1-C5. Volume 3: Appendices D1-D3 and E

Two categories were chosen for study: the issue of using a preprocessor on Ada code of Application Programs which would interface with the Run-Time Object Data Base Standard Services (RODB STSV), the intent was to catch and correct any mis-registration errors of the program coder between the user declared Objects, their types, their addresses, and the corresponding RODB definitions; and RODB STSV Performance Issues and Identification of Problems with the planned methods for accessing Primitive Object Attributes, this included the study of an alternate storage scheme to the 'store objects by attribute' scheme in the current design of the RODB. The study resulted in essentially three separate documents, an interpretation of the system requirements, an assessment of the preliminary design, and a detailing of the components of a detailed design.

Leibfried, T. F., Jr.↗
NASA NTRS1999

"An On-Line Access System for TRMM Data"

The Tropical Rainfall Measuring Mission (TRMM), jointly sponsored by the National Aeronautics and Space Administration (NASA) of United States and the National Space Development Agency (NASDA) of Japan, provides visible, infrared, and microwave observations of tropical and subtropical rain system. The satellite observations are complemented by ground radar and rain gauge measurements to validate satellite rain estimation techniques. TRMM satellite was launched on November 27, 1997(EST). Data from TRMM are being archived, processed, and disseminated by DAAC at the Goddard Space Flight Center (GSFC) of NASA. The Goddard DAAC has been archiving Tropical Rainfall Measuring Mission (TRMM) data since the launch. The TRMM level 1 and level 2 products first have been released to public on June 15, 1998. Now, most of TRMM products, including some ground validation products are released to public. TRMM data are useful for forecast model research, disaster mitigation, climatological studies, agricultural predictions, and many other applications. An online system or user interface is designed for easy, friendly, and quick display, access, and ordering of the TRMM data. Components, features, and limitations of the system will be discussed and demonstrated. The TRMM standard products and variety of the subsets and ancillary data will be shown, and their availability will be discussed.

Rui, Hualan↗
NASA NTRS2002

The spacecraft onboard interface standardization activity

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.

spacecraft interfaces standard interfaces CCSDS↗
NASA NTRS1991

Ada and the rapid development lifecycle

JPL is under contract, through NASA, with the US Army to develop a state-of-the-art Command Center System for the US European Command (USEUCOM). The Command Center System will receive, process, and integrate force status information from various sources and provide this integrated information to staff officers and decision makers in a format designed to enhance user comprehension and utility. The system is based on distributed workstation class microcomputers, VAX- and SUN-based data servers, and interfaces to existing military mainframe systems and communication networks. JPL is developing the Command Center System utilizing an incremental delivery methodology called the Rapid Development Methodology with adherence to government and industry standards including the UNIX operating system, X Windows, OSF/Motif, and the Ada programming language. Through a combination of software engineering techniques specific to the Ada programming language and the Rapid Development Approach, JPL was able to deliver capability to the military user incrementally, with comparable quality and improved economies of projects developed under more traditional software intensive system implementation methodologies.

Deforrest, Lloyd↗
NASA NTRS1996

An optimal user-interface for EPIMS database conversions and SSQ 25002 EEE parts screening

The Electrical, Electronic, and Electromechanical (EEE) Parts Information Management System (EPIMS) database was selected by the International Space Station Parts Control Board for providing parts information to NASA managers and contractors. Parts data is transferred to the EPIMS database by converting parts list data to the EP1MS Data Exchange File Format. In general, parts list information received from contractors and suppliers does not convert directly into the EPIMS Data Exchange File Format. Often parts lists use different variable and record field assignments. Many of the EPES variables are not defined in the parts lists received. The objective of this work was to develop an automated system for translating parts lists into the EPIMS Data Exchange File Format for upload into the EPIMS database. Once EEE parts information has been transferred to the EPIMS database it is necessary to screen parts data in accordance with the provisions of the SSQ 25002 Supplemental List of Qualified Electrical, Electronic, and Electromechanical Parts, Manufacturers, and Laboratories (QEPM&L). The SSQ 2S002 standards are used to identify parts which satisfy the requirements for spacecraft applications. An additional objective for this work was to develop an automated system which would screen EEE parts information against the SSQ 2S002 to inform managers of the qualification status of parts used in spacecraft applications. The EPIMS Database Conversion and SSQ 25002 User Interfaces are designed to interface through the World-Wide-Web(WWW)/Internet to provide accessibility by NASA managers and contractors.

Watson, John C.↗
NASA NTRS2002

The spacecraft onboard interface standardization activity

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.

spacecraft interfaces standard interfaces CCSDS↗
NASA NTRS1991

Higher-order neural network software for distortion invariant object recognition

The state-of-the-art in pattern recognition for such applications as automatic target recognition and industrial robotic vision relies on digital image processing. We present a higher-order neural network model and software which performs the complete feature extraction-pattern classification paradigm required for automatic pattern recognition. Using a third-order neural network, we demonstrate complete, 100 percent accurate invariance to distortions of scale, position, and in-plate rotation. In a higher-order neural network, feature extraction is built into the network, and does not have to be learned. Only the relatively simple classification step must be learned. This is key to achieving very rapid training. The training set is much smaller than with standard neural network software because the higher-order network only has to be shown one view of each object to be learned, not every possible view. The software and graphical user interface run on any Sun workstation. Results of the use of the neural software in autonomous robotic vision systems are presented. Such a system could have extensive application in robotic manufacturing.

Reid, Max B.↗
NASA NTRS1994

Common modeling system for digital simulation

The Joint Modeling and Simulation System is a tri-service investigation into a common modeling framework for the development digital models. The basis for the success of this framework is an X-window-based, open systems architecture, object-based/oriented methodology, standard interface approach to digital model construction, configuration, execution, and post processing. For years Department of Defense (DOD) agencies have produced various weapon systems/technologies and typically digital representations of the systems/technologies. These digital representations (models) have also been developed for other reasons such as studies and analysis, Cost Effectiveness Analysis (COEA) tradeoffs, etc. Unfortunately, there have been no Modeling and Simulation (M&S) standards, guidelines, or efforts towards commonality in DOD M&S. The typical scenario is an organization hires a contractor to build hardware and in doing so an digital model may be constructed. Until recently, this model was not even obtained by the organization. Even if it was procured, it was on a unique platform, in a unique language, with unique interfaces, and, with the result being UNIQUE maintenance required. Additionally, the constructors of the model expended more effort in writing the 'infrastructure' of the model/simulation (e.g. user interface, database/database management system, data journalizing/archiving, graphical presentations, environment characteristics, other components in the simulation, etc.) than in producing the model of the desired system. Other side effects include: duplication of efforts; varying assumptions; lack of credibility/validation; and decentralization in policy and execution. J-MASS provides the infrastructure, standards, toolset, and architecture to permit M&S developers and analysts to concentrate on the their area of interest.

Painter, Rick↗
NASA NTRS2014

Using Social Media and Mobile Devices to Discover and Share Disaster Data Products Derived From Satellites

Data products derived from Earth observing satellites are difficult to find and share without specialized software and often times a highly paid and specialized staff. For our research effort, we endeavored to prototype a distributed architecture that depends on a standardized communication protocol and applications program interface (API) that makes it easy for anyone to discover and access disaster related data. Providers can easily supply the public with their disaster related products by building an adapter for our API. Users can use the API to browse and find products that relate to the disaster at hand, without a centralized catalogue, for example floods, and then are able to share that data via social media. Furthermore, a longerterm goal for this architecture is to enable other users who see the shared disaster product to be able to generate the same product for other areas of interest via simple point and click actions on the API on their mobile device. Furthermore, the user will be able to edit the data with on the ground local observations and return the updated information to the original repository of this information if configured for this function. This architecture leverages SensorWeb functionality [1] presented at previous IGARSS conferences. The architecture is divided into two pieces, the frontend, which is the GeoSocial API, and the backend, which is a standardized disaster node that knows how to talk to other disaster nodes, and also can communicate with the GeoSocial API. The GeoSocial API, along with the disaster node basic functionality enables crowdsourcing and thus can leverage insitu observations by people external to a group to perform tasks such as improving water reference maps, which are maps of existing water before floods. This can lower the cost of generating precision water maps. Keywords-Data Discovery, Disaster Decision Support, Disaster Management, Interoperability, CEOS WGISS Disaster Architecture

0↗
NASA NTRS2003

Standard user data services for spacecraft applications

The Consultative Committee for Space Data Systems is an international organization of national space agencies that is branching out to provide new standards to enhanced reuse of spacecraft equiptment and software. These Spacecraft Onboard Interface (SOIF) standards will be based on the well-known Internet protocols. this paper will review the SOIF standards by looking at the services that are being proposed for SOIF.

space interfaces avionics interfaces standard inte↗
NASA NTRS2019

Harmony: Bringing Data Together by Bringing Services Together

As Earth observation data volume, velocity, and variety continues to accelerate, so do the challenges of working with those data. The computation, storage, and network transfer requirements for multi-petabyte datasets demand solutions that allow users to process, store, and move fewer bytes while still finding the valuable insights they seek. Our cloud-based data transformation framework, Harmony, tackles these challenges by providing consistent, standards-based interface to multiple disparate backend processors collocated with NASA EOSDIS data. It allows data scientists to perform data processing and harmonization activities across many datasets through familiar tooling. Simultaneously, it provides a clear, consistent interface for data providers to expose new or customized backend services for their data. This talk will discuss Harmony, its architecture and interface, and the path forward for cloud-based NASA EOSDIS data harmonization services.

Quinn, Patrick↗
NASA NTRS2010

The Evolvable Advanced Multi-Mission Operations System (AMMOS): Making Systems Interoperable

The Advanced Multi-Mission Operations System (AMMOS) provides a common Mission Operation System (MOS) infrastructure to NASA deep space missions. The evolution of AMMOS has been driven by two factors: increasingly challenging requirements from space missions, and the emergence of new IT technology. The work described in this paper focuses on three key tasks related to IT technology requirements: first, to eliminate duplicate functionality; second, to promote the use of loosely coupled application programming interfaces, text based file interfaces, web-based frameworks and integrated Graphical User Interfaces (GUI) to connect users, data, and core functionality; and third, to build, develop, and deploy AMMOS services that are reusable, agile, adaptive to project MOS configurations, and responsive to industrially endorsed information technology standards.

MGSS↗
NASA NTRS2006

Tool for Statistical Analysis and Display of Landing Sites

MarsLS is a software tool for analyzing statistical dispersion of spacecraft-landing sites and displaying the results of its analyses. Originally intended for the Mars Explorer Rover (MER) mission, MarsLS is also applicable to landing sites on Earth and non-MER sites on Mars. MarsLS is a collection of interdependent MATLAB scripts that utilize the MATLAB graphical-user-interface software environment to display landing-site data (see figure) on calibrated image-maps of the Martian or other terrain. The landing-site data comprise latitude/longitude pairs generated by Monte Carlo runs of other computer programs that simulate entry, descent, and landing. Using these data, MarsLS can compute a landing-site ellipse a standard means of depicting the area within which the spacecraft can be expected to land with a given probability. MarsLS incorporates several features for the user s convenience, including capabilities for drawing lines and ellipses, overlaying kilometer or latitude/longitude grids, drawing and/or specifying lines and/or points, entering notes, defining and/or displaying polygons to indicate hazards or areas of interest, and evaluating hazardous and/or scientifically interesting areas. As part of such an evaluation, MarsLS can compute the probability of landing in a specified polygonal area.

Wawrzyniak, Geoffrey↗