SEARCH · Engineering Papers

Results for “linking software”

Search indexed NASA NTRS and DOE OSTI research on propulsion, heat transfer, battery materials and energy systems. Follow report and document links to the original sources.

SourceResearch connectionFrom yearThrough year

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

At least 73 records · Page 4

All sources NASA NTRS DOE OSTI

NASA NTRS1985

Managing Software Design and Design Changes

Microprocessor-based system for document production work scheduling, and change control and management information aids in design, development, and control of software. Main components Z80 microprocessor, floppydisk and hard-disk drives, and a character printer. System linked to large computer. Major software components are control program monitor (CP/M), text-editing and wordprocessing system, workbreakdown-schedule processor, and data-base management tool.

Loesh, R. E.↗

NASA NTRS2006

Partial Automation of Requirements Tracing

Requirements Tracing on Target (RETRO) is software for after-the-fact tracing of textual requirements to support independent verification and validation of software. RETRO applies one of three user-selectable information-retrieval techniques: (1) term frequency/inverse document frequency (TF/IDF) vector retrieval, (2) TF/IDF vector retrieval with simple thesaurus, or (3) keyword extraction. One component of RETRO is the graphical user interface (GUI) for use in initiating a requirements-tracing project (a pair of artifacts to be traced to each other, such as a requirements spec and a design spec). Once the artifacts have been specified and the IR technique chosen, another component constructs a representation of the artifact elements and stores it on disk. Next, the IR technique is used to produce a first list of candidate links (potential matches between the two artifact levels). This list, encoded in Extensible Markup Language (XML), is optionally processed by a filtering component designed to make the list somewhat smaller without sacrificing accuracy. Through the GUI, the user examines a number of links and returns decisions (yes, these are links; no, these are not links). Coded in XML, these decisions are provided to a "feedback processor" component that prepares the data for the next application of the IR technique. The feedback reduces the incidence of erroneous candidate links. Unlike related prior software, RETRO does not require the user to assign keywords, and automatically builds a document index.

Hayes, Jane↗

NASA NTRS1982

The Shuttle inertial system

The Space Shuttle inertial system is built around a sensor assembly called the inertial measurement unit (IMU). The system includes a redundant set of three structurally integrated IMU's that operate in conjunction with parallel strung data system computers to provide precise attitude and velocity information to user system functions. The inertial system is actually a separate subsystem function integrated into the overall avionics system. Software resident in the system computers is the final link in the inertial system. The inertial software is comprised of two major sets, including a subsystem operating program (SOP) called the IMU SOP and redundancy management. Attention is given to system applications, systems performance, attitude sensitivities, the IMU platform, IMU thermal management, aspects of IMU calibration, and Shuttle program experience.

Swingle, W. L.↗

NASA NTRS1987

Comparison of two transonic noise prediction formulations using the aircraft noise prediction program

This paper addresses recently completed work on using Farassat's Formulation 3 noise prediction code with the Aircraft Noise Prediction Program (ANOPP). Software was written to link aerodynamic loading generated by the Propeller Loading (PLD) module within ANOPP with formulation 3. Included are results of comparisons between Formulation 3 with ANOPP's existing noise prediction modules, Subsonic Propeller Noise (SPN) and Transonic Propeller Noise (TPN). Four case studies are investigated. Results of the comparison studies show excellent agreement for the subsonic cases. Differences found in the comparisons made under transonic conditions are strictly numerical and can be explained by the way in which the time derivative is calculated in Formulation 3. Also included is a section on how to execute Formulation 3 with ANOPP.

Spence, Peter L.↗

NASA NTRS1994

Personal Computer Monitors Instrumentation Bus

IBM-compatible personal computer used instead of logic analyzer or other special instrument to monitor IEEE-488 interface data bus that interconnects various pieces of laboratory equipment. Needed is short program for computer, commercial general-purpose interface bus circuit card, and adapter cable to link card to bus. Software available in Ada or Quick Basic language.

Conroy, Bruce L.↗

NASA NTRS1981

Air Combat Simulator

By adapting COSMIC's One-on-One Adaptive Maneuvering Logic (AML) for two versus one simulation, Link Division was able to reduce software and other design/development costs. Enhancements to the AML program developed by Link for simulation of two-versus one combat, two trainees can simultaneously engage a computer driven target, thereby doubling the training utility of the simulator.

Source record↗

NASA NTRS2011

DAQ: Software Architecture for Data Acquisition in Sounding Rockets

A multithreaded software application was developed by Jet Propulsion Lab (JPL) to collect a set of correlated imagery, Inertial Measurement Unit (IMU) and GPS data for a Wallops Flight Facility (WFF) sounding rocket flight. The data set will be used to advance Terrain Relative Navigation (TRN) technology algorithms being researched at JPL. This paper describes the software architecture and the tests used to meet the timing and data rate requirements for the software used to collect the dataset. Also discussed are the challenges of using commercial off the shelf (COTS) flight hardware and open source software. This includes multiple Camera Link (C-link) based cameras, a Pentium-M based computer, and Linux Fedora 11 operating system. Additionally, the paper talks about the history of the software architecture's usage in other JPL projects and its applicability for future missions, such as cubesats, UAVs, and research planes/balloons. Also talked about will be the human aspect of project especially JPL's Phaeton program and the results of the launch.

Ahmad, Mohammad↗

NASA NTRS2012

Mars Express Forward Link Capabilities for the Mars Relay Operations Service (MaROS)

This software provides a new capability for landed Mars assets to perform forward link relay through the Mars Express (MEX) European Union orbital spacecraft. It solves the problem of standardizing the relay interface between lander missions and MEX. The Mars Operations Relay Service (MaROS) is intended as a central point for relay planning and post-pass analysis for all Mars landed and orbital assets. Through the first two phases of implementation, MaROS supports relay coordination through the Odyssey orbiter and the Mars Reconnaissance Orbiter (MRO). With this new software, MaROS now fully integrates the Mars Express spacecraft into the relay picture. This new software generates and manages a new set of file formats that allows for relay request to MEX for forward and return link relay, including the parameters specific to MEX. Existing MEX relay planning interactions were performed via email exchanges and point-to-point file transfers. By integrating MEX into MaROS, all transactions are managed by a centralized service for tracking and analysis. Additionally, all lander missions have a single, shared interface with MEX and do not have to integrate on a mission-by mission basis. Relay is a critical element of Mars lander data management. Landed assets depend largely upon orbital relay for data delivery, which can be impacted by the availability and health of each orbiter in the network. At any time, an issue may occur to prevent relay. For this reason, it is imperative that all possible orbital assets be integrated into the overall relay picture.

Allard, Daniel A.↗

NASA NTRS2010

Unified Approach to Modeling and Simulation of Space Communication Networks and Systems

Network simulator software tools are often used to model the behaviors and interactions of applications, protocols, packets, and data links in terrestrial communication networks. Other software tools that model the physics, orbital dynamics, and RF characteristics of space systems have matured to allow for rapid, detailed analysis of space communication links. However, the absence of a unified toolset that integrates the two modeling approaches has encumbered the systems engineers tasked with the design, architecture, and analysis of complex space communication networks and systems. This paper presents the unified approach and describes the motivation, challenges, and our solution - the customization of the network simulator to integrate with astronautical analysis software tools for high-fidelity end-to-end simulation. Keywords space; communication; systems; networking; simulation; modeling; QualNet; STK; integration; space networks

Barritt, Brian↗

NASA NTRS1982

Optimum waiting time for acquisition of return link PN signals

The subject of this paper is a model that takes into account the effect that acquisition of a PN signal on the forward link has on the acquisition of a PN signal on the return link. The model is used to determine how long the start of the PN search on the return link should be delayed in order to minimize the combined acquisition time (delay + acquisition time) as a function of desired acquisition probability. It is assumed that the return link a-priori epoch uncertainty information is available. Software has been developed that models the return link PN receiver and incorporates in it the effect of forward link PN acquisition statistics in assessing performance.

Kolata, W.↗

NASA NTRSDate not supplied

Integration of Structural Analysis and Manufacturing Process Planning for Global Optimization with Automated Fiber Placement

Design of mass-efficient composite structures intended for Automated Fiber Placement (AFP) requires close interaction between structural analysis and manufacturing process planning. Tools exist for each of these disciplines, but software interplay has been insufficient for rapid and efficient design iteration. Within the NASA Advanced Composites Consortium (ACC), the Design for Manufacturing (DFM) task has made significant progress towards linking these disciplines and respective software – HyperX (design), CAPP (process planning), and VCP (tool path generation). The initial focus in previous work was on data exchange between disciplines. The ability to both export and consume composite design and manufacturing data to and from each tool. This paper focuses on the effort to automate and streamline the connection between the tools listed above, with the goal of being able to automatically generate a composite AFP design that is mass-efficient and manufacturable. The optimization method being pursued is a bi-level approach, where each tool performs optimization within its discipline. The optimization in HyperX is focused on mass and laminate strength, while CAPP is focused on maximizing manufacturability. VCP is used to generate fiber paths for each design iteration. These sub-processes are wrapped with a global level optimization, driven by HyperX, used to converge the design. This paper describes the current state of this effort, which is a completed HyperX-VCP iteration loop and initial work on the HyperX-CAPP iteration loop. Additionally, example results are shown for a wind blade structure with double curvature.

Automated Fiber Placement↗

NASA NTRS1992

Development of the FITS tools package for multiple software environments

The HEASARC is developing a package of general purpose software for analyzing data files in FITS format. This paper describes the design philosophy which makes the software both machine-independent (it runs on VAXs, Suns, and DEC-stations) and software environment-independent. Currently the software can be compiled and linked to produce IRAF tasks, or alternatively, the same source code can be used to generate stand-alone tasks using one of two implementations of a user-parameter interface library. The machine independence of the software is achieved by writing the source code in ANSI standard Fortran or C, using the machine-independent FITSIO subroutine interface for all data file I/O, and using a standard user-parameter subroutine interface for all user I/O. The latter interface is based on the Fortran IRAF Parameter File interface developed at STScI. The IRAF tasks are built by linking to the IRAF implementation of this parameter interface library. Two other implementations of this parameter interface library, which have no IRAF dependencies, are now available which can be used to generate stand-alone executable tasks. These stand-alone tasks can simply be executed from the machine operating system prompt either by supplying all the task parameters on the command line or by entering the task name after which the user will be prompted for any required parameters. A first release of this FTOOLS package is now publicly available. The currently available tasks are described, along with instructions on how to obtain a copy of the software.

Pence, W. D.↗

NASA NTRS2018

The Utilization Profiles of the CCSDS Unified Space Link Protocol (USLP)

The purpose of this paper is to identify the utilization profiles for interfacing the Data Protocol Sublayer using the Unified Space Link Protocols (USLP) (reference 1) with the space link coding procedures as specified in the CCSDS Coding & Synchronization Blue Books (references 2 through 5), used in both telecommand and telemetry applications. This paper describes how the USLP Protocol utilizes the coding and synchronization sublayer to support: a. Direct to Earth (DTE) telemetry links for engineering and science data b. Direct to Earth (DTE) telemetry links for very high rate science data c. Direct from Earth (DFE) command, sequencing and flight software loads d. Space to Space Links (Proximity) utilized by orbiters for data exchange to/from surface bound assets. The CCSDS has divided the functions of the Data Link Layer into two sublayers: the Data Link Protocol Sublayer (DLP-SL) and the Coding and Synchronization Sublayer (CS-SL). The Data Link Protocol Sublayer (DLP-SL) interfaces to the users, accepting the data that is to be transported, on the sending side of the link, and delivering that data on the receiving end. The Transfer Frame is the data unit that is transferred across the Data Link Protocol Sublayer and the Coding and Synchronization Sublayer boundary. The Coding and Synchronization Sublayer (CS-SL) provides the encoding, randomization, and frame synchronization functions that prepares the USLP Transfer Frame for transport across the space link. The CS-SL is divided into 2 processes: 1) The Frame Interface Processes (FIP) performs the interface functions required to prepare the data for delivery to the Coding/Decoding Process (CDP). This process includes prepending a Frame Start Marker to the provided frame, when management has designated that the frame is not to be aligned to the codeblock or when there is no block code used. 2) The Coding/Decoding Process (CDP) performs the forward error correction processes that are used to optimize the performance of the link and minimize the error rate. The CDP creates the symbol stream that is delivered to the Physical Layer. The transfer of the USLP transfer frames across different types of space links is the focus of this paper. The Protocol Data Unit (PDU) that is passed in both directions between the Data Link Protocol Sublayer (DLP-SL) and Coding and Synchronization Sublayer (CS-SL) is the transfer frame. The USLP frame structure provides flexibility that can be constrained by the functions utilized within the CS-SL that prepare the transfer frame for transit. For example, the USLP transfer frame contains a length field that enables the frame to be of variable length but CS-SL under certain conditions may constrain the frame to be fixed in length. This paper describes 5 operational modes available for use by the Data Link Layer to provide data exchange across the USLP space link. These modes are different because different operational requirements apply to vastly different types of space links and thus the communications implementation requirements differ. The environmental issues include the power or energy available, the distance between the end points of the link, the complexity of the equipment available at those end points, the atmospheric conditions and radiometric frequency selection. The CS-SL utilizes different forward error correcting codes supported by specific operational modes to configure the data for transit. This paper describes all of the operational modes in a series of data models which decompose the functionality between the Data Link Protocol Sublayer and the Coding and Synchronization sublayer. The operational modes described are: 1. Uncoded Mode: has been used for short links that contain significant available power to provide an acceptable frame error rate. The frames in this mode can be variable in length and typically use an error detection algorithm (i.e., CRC) to determine if there are errors in the received frame. 2. Convolutional Only Mode: is currently the prime forward error correction coding used for the proximity links. The frames in this mode can be variable in length and typically use an error detection algorithm (i.e., CRC) to determine if there are errors in the received frame. 3. Variable Length Frame Aligned to Variable Length Codeblock (TC): is used for Direct from Earth links were power levels are high and the simple, least complex code i.e., the BCH code is used. This mode has been in use since the early 1970s. The BCH code is a short code and the decoder is easy to implement. 4. Fixed Length Frame Aligned to Fixed Length Codeblock (AOS/TM): was introduced when the concatenated Convolutional and Reed-Solomon Code was formulated to provide significant reduction in link data error rate and the ability to determine if there was an error in the decoded codeblock. The frame is aligned to the codeblock so that there is a one to one relationship of frame errors to codeblock errors without additional error detection coding being added. This mode requires the protocol frames to be the exact size of the message portion of the codeblock. 5. Frames Unaligned to Fixed Length Codeblocks (Currently used for very high rates and space to space links): This mode is currently used for missions that have a very high data rate that can be controlled adaptively as the environment changes and as the next generation operating mode for the proximity link. This mode from a coded data stream point of view is exactly like that described in 4. above, except that the frame need not be aligned to the codeblock. There is no requirement on frame length when using this mode. Thus when using USLP it can be used to support links that require short or long frames. There is also no mandatory requirement that frames cannot be separated by idle data reducing the tight data rate connection requirements between the data link protocol sublayer and the coding & synchronization sublayer. In conclusion, how these operational modes can be put to use in mission operational scenarios is described for Direct from Earth links (DFE), Direct to Earth links (DTE), and Proximity links.

Greenberg, E.↗

NASA NTRS2010

Data Products for the OCTL to OICETS Optical Link Experiment

JPL has developed a series of software and hardware tools to analyze and record data from a 50Mb/s down and 2 Mb/s up bi-directional optical link with the LUCE terminal onboard the LEO OICETS satellite. This paper presents the data products for this experiment including the system architecture and analysis of the actual data received.

optical communications↗

NASA NTRS2014

Passive Thermal Design Approach for the Space Communications and Navigation (SCaN) Testbed Experiment on the International Space Station (ISS)

The Space Communications and Navigation (SCaN) Program Office at NASA Headquarters oversees all of NASAs space communications activities. SCaN manages and directs the ground-based facilities and services provided by the Deep Space Network (DSN), Near Earth Network (NEN), and the Space Network (SN). Through the SCaN Program Office, NASA GRC developed a Software Defined Radio (SDR) testbed experiment (SCaN testbed experiment) for use on the International Space Station (ISS). It is comprised of three different SDR radios, the Jet Propulsion Laboratory (JPL) radio, Harris Corporation radio, and the General Dynamics Corporation radio. The SCaN testbed experiment provides an on-orbit, adaptable, SDR Space Telecommunications Radio System (STRS) - based facility to conduct a suite of experiments to advance the Software Defined Radio, Space Telecommunications Radio Systems (STRS) standards, reduce risk (Technology Readiness Level (TRL) advancement) for candidate Constellation future space flight hardware software, and demonstrate space communication links critical to future NASA exploration missions. The SCaN testbed project provides NASA, industry, other Government agencies, and academic partners the opportunity to develop and field communications, navigation, and networking technologies in the laboratory and space environment based on reconfigurable, software defined radio platforms and the STRS Architecture.The SCaN testbed is resident on the P3 Express Logistics Carrier (ELC) on the exterior truss of the International Space Station (ISS). The SCaN testbed payload launched on the Japanese Aerospace Exploration Agency (JAXA) H-II Transfer Vehicle (HTV) and was installed on the ISS P3 ELC located on the inboard RAM P3 site. The daily operations and testing are managed out of NASA GRC in the Telescience Support Center (TSC).

Passive Thermal Design↗

NASA NTRS1991

Knowledge-based processing for aircraft flight control

The purpose is to develop algorithms and architectures for embedding artificial intelligence in aircraft guidance and control systems. With the approach adopted, AI-computing is used to create an outer guidance loop for driving the usual aircraft autopilot. That is, a symbolic processor monitors the operation and performance of the aircraft. Then, based on rules and other stored knowledge, commands are automatically formulated for driving the autopilot so as to accomplish desired flight operations. The focus is on developing a software system which can respond to linguistic instructions, input in a standard format, so as to formulate a sequence of simple commands to the autopilot. The instructions might be a fairly complex flight clearance, input either manually or by data-link. Emphasis is on a software system which responds much like a pilot would, employing not only precise computations, but, also, knowledge which is less precise, but more like common-sense. The approach is based on prior work to develop a generic 'shell' architecture for an AI-processor, which may be tailored to many applications by describing the application in appropriate processor data bases (libraries). Such descriptions include numerical models of the aircraft and flight control system, as well as symbolic (linguistic) descriptions of flight operations, rules, and tactics.

Painter, John H.↗

NASA NTRS1983

User manual of the CATSS system (version 1.0) communication analysis tool for space station

The Communication Analysis Tool for the Space Station (CATSS) is a FORTRAN language software package capable of predicting the communications links performance for the Space Station (SS) communication and tracking (C & T) system. An interactive software package was currently developed to run on the DEC/VAX computers. The CATSS models and evaluates the various C & T links of the SS, which includes the modulation schemes such as Binary-Phase-Shift-Keying (BPSK), BPSK with Direct Sequence Spread Spectrum (PN/BPSK), and M-ary Frequency-Shift-Keying with Frequency Hopping (FH/MFSK). Optical Space Communication link is also included. CATSS is a C & T system engineering tool used to predict and analyze the system performance for different link environment. Identification of system weaknesses is achieved through evaluation of performance with varying system parameters. System tradeoff for different values of system parameters are made based on the performance prediction.

Tsang, C. S.↗

NASA NTRS1993

System For Retrieving Reusable Software

Encyclopedia of Software Components (ESC) is information-retrieval system of computer hardware and software providing access to generic reusable software tools and parts. Core of ESC is central tool base, which is repository of reusable software. It receives queries and submissions from user through local browser subsystem and receives authorized updates from maintenance subsystem. Sends retrievals to local browser subsystem and user's submissions to maintenance subsystem. Future versions will provide for advanced media, including voice and video, and will link system to database-management system. Programmers will not only retrieve software, but also modify, execute, and cross-link with other software.

Van Warren, Lloyd↗