Engineering Papers⌕ Search

SEARCH · Engineering Papers

Results for “Firmware”

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 37 records · Page 2
All sourcesNASA NTRSDOE OSTI
NASA NTRS2011

10-100 Gbps Offload NIC for WAN, NLR, and Grid Computing

An extremely fast offload engine system has been developed that operates at 60 Gigabits per second (Gbps), and has scalability to 100 Gbps full-duplex (f-d). This system is based on unique coding and architecture derived from splintered UDP (User Datagram Protocol) offload technology, resulting in unique FPGA (field programmable gate array) intellectual property core and firmware. This innovation improves the networking speed of supercomputer clusters by providing an ultra-fast network protocol processing offload from a CPU (central processing unit) by inserting an offload engine into a host backplane and network connections. This runs on protocol firmware.

Awrach, James↗
NASA NTRS2017

Field Programmable Gate Array Failure Rate Estimation Guidelines for Launch Vehicle Fault Tree Models

Today's launch vehicles complex electronic and avionic systems heavily utilize the Field Programmable Gate Array (FPGA) integrated circuit (IC). FPGAs are prevalent ICs in communication protocols such as MIL-STD-1553B, and in control signal commands such as in solenoid/servo valves actuations. This paper will demonstrate guidelines to estimate FPGA failure rates for a launch vehicle, the guidelines will account for hardware, firmware, and radiation induced failures. The hardware contribution of the approach accounts for physical failures of the IC, FPGA memory and clock. The firmware portion will provide guidelines on the high level FPGA programming language and ways to account for software/code reliability growth. The radiation portion will provide guidelines on environment susceptibility as well as guidelines on tailoring other launch vehicle programs historical data to a specific launch vehicle.

Al Hassan, Mohammad↗
NASA NTRS2021

DSN Radio Astronomy Spectrometer

The Deep Space Network (DSN) enables NASA to communicate with its deep space spacecraft. By virtue of its large antennas, the DSN can be used as a powerful instrument for radio astronomy. In particular, Deep Space Station (DSS) 43, the 70 m antenna at the Canberra Deep Space Communications Complex (CDSCC) has a K-band radio astronomy system covering a 10 GHz bandwidth at 17 to 27 GHz. This spectral range covers a number of atomic and molecular lines, produced in a rich variety of interstellar gas conditions. A new high-resolution spectrometer was deployed at CDSCC in November 2019 and connected to the K-band downconverter. The system has two different firmware modes: 1) Using a 65k-pt FFT to provide 32,768 spectral channels at ~30.5 kHz (0.45 km/s velocity resolution) and 2) Using a 16k-pt polyphase filterbank (PFB) to provide 8,192 spectral channels with ~122 kHz resolution (1.8 km/s velocity resolution). Previous work extensively described the spectrometer system. In this paper we present added functionality and updates to the commissioned spectrometer. The changes include developments in system timing, metadata, firmware and data products.

Bradford, Brian↗
NASA NTRS2021

Scheduling and Operations of the ECOSTRESS Mission

This paper describes the development and use of an automated scheduling system for the National Aeronautics and Space Administration’s (NASA) ECOsystem Spaceborne Thermal Radiometer Experiment on Space Station (ECOSTRESS) mission. Key to the success of the ECOSTRESS mission has been the use of automated scheduling in mission analysis pre-launch, and in successful operations where automated scheduling was deployed to address several operational challenges. ECOSTRESS uses an adaptation of the Compressed Large-scale Activity Scheduling and Planning (CLASP) system to automatically select science observations respecting area and point target priorities as well as visibility, illumination, onboard storage, and radiation constraints to satisfy high-level prioritized science campaigns. The ECOSTRESS scheduler was used pre-launch to predict the effectiveness of alternative formulations of science campaign definitions accounting for the impact of data volume, keepout, and orbit/illumination/visibility constraints to derive the initial operational science campaign definitions and priorities. The scheduler was then used after instrument checkout for operations. ECOSTRESS has faced multiple operational challenges relating to instrument firmware and hardware, and the scheduler has been updated several times to address these challenges. The instrument Mass Storage Units (MSUs) had operational issues, requiring the scheduler to plan for and schedule commands to handle intricacies of data management. After many months of operations, both MSUs on the instrument became non-functioning and the firmware of the instrument was updated to bypass the MSUs. A further update to the ECOSTRESS scheduler enabled the scheduler to operate in this new operations mode. The ECOSTRESS scheduler has also been updated to improve handling of along-track uncertainty inherent in International Space Station operations. The flexibility and ease of updating of the automated scheduler has been a significant contributor to successful operations of the ECOSTRESS mission.

Padams, Jordan↗
NASA NTRSDate not supplied

Fault Management Algorithm Risk Assessment for the NASA Space Launch System

This paper presents the false positive (FP) and false negative (FN) risk assessment process currently being conducted for the Space Launch System (SLS) Artemis II Fault Management (FM) detection functions. The analysis scope, general assumptions and guide rules, and key modeling concepts were discussed to establish the basis of the risk assessments conducted. Initial analyses indicated a dominance in the total risk by software and firmware failures. This paper presents efforts applied to refine the software risks and the overall impact of implementing those modifications. Current analyses conducted on the detection functions implemented for the SLS Artemis II mission indicate primary risk drivers for the individual FM detection functions are flight software failures, firmware design failures, and hardware Common Cause Failures (CCFs). There still remains issues of how to account for time and redundancy in the software risk estimations.

probability risk analysis↗
NASA NTRSDate not supplied

Fault Management Algorithm Risk Assessment for the NASA Space Launch System

This presentation describes the false positive (FP) and false negative (FN) risk assessment process currently being conducted for the Space Launch System (SLS) Artemis II Fault Management (FM) detection functions. The analysis scope, general assumptions and guide rules, and key modeling concepts were discussed to establish the basis of the risk assessments conducted. Initial analyses indicated a dominance in the total risk by software and firmware failures. This paper presents efforts applied to refine the software risks and the overall impact of implementing those modifications. Current analyses conducted on the detection functions implemented for the SLS Artemis II mission indicate primary risk drivers for the individual FM detection functions are flight software failures, firmware design failures, and hardware Common Cause Failures (CCFs). There still remains issues of how to account for time and redundancy in the software risk estimations.

probability risk analysis↗
NASA NTRSDate not supplied

Lessons Learned from Astrobee Operations on the International Space Station

Since its launch in 2019, NASA has been operating three Astrobee free-flying robots providing an autonomous and adaptable research platform aboard the International Space Station (ISS). These robots have not only facilitated a myriad of national and international research endeavors in microgravity but have also served as a STEM outreach platform for student competitions aboard the ISS. Amidst its extensive operational tenure, spanning over five years and exceeding 1200 hours of cumulative free-flyer operation as of April 2024, the Astrobee robots have encountered software and hardware anomalies. Despite its inherent design for on-orbit repair or replacement, certain anomalies have proven to be complex, necessitating remote resolution via software and firmware updates or, in extreme cases, hardware replacements or the return of faulty units to NASA's ground facilities for repair. Such challenges underscore the delicate balance between the autonomous functionality of Astrobee and the occasional need for human intervention to maintain optimal performance. One recurring point of failure identified during Astrobee's operational lifespan has been the SD card, a critical component utilized by the different Astrobee processors and the Dock Station. The occurrence of SD card anomalies, both on orbit and within ground units, has provided invaluable insights into the improvement of Astrobee's systems and mitigation to future faults. This presentation will focus on four key areas: 1. Overview of Faults and Anomalies: A comprehensive examination of the diverse array of faults and anomalies encountered by Astrobee and its associated systems both in orbit and on the ground. From software glitches to hardware malfunctions, this section provides insights into the challenges faced during Astrobee's operational tenure. 2. Resolution Processes and Procedures: An in-depth discussion of the methodologies and procedures implemented to resolve the encountered anomalies. This includes remote troubleshooting, software patches, firmware updates, and, when necessary, the logistics involved in hardware replacements or down-massing for repair. 3. Implementation of Software Updates and Hardware Upgrades: A detailed exploration of the strategies employed to mitigate the risk of recurring anomalies through the implementation of software updates and hardware upgrades. This section highlights the iterative nature of Astrobee's development, emphasizing the continuous pursuit of robustness and reliability. 4. Lessons Learned and Future Directions: Reflecting on the insights gained from addressing anomalies, this section examines the lessons learned and outlines future directions for enhancing Astrobee's robustness and resilience. It underscores the iterative nature of space exploration and the importance of adaptability and continuous improvement in the pursuit of scientific discovery. Through a nuanced examination of Astrobee's operational challenges and the strategies employed to overcome them, this presentation sheds light on the complexities of operating autonomous robotic systems in the ISS environment. It underscores NASA's commitment to pushing the boundaries of exploration and innovation while navigating the inherent challenges of space exploration.

Astrobee↗
NASA NTRSDate not supplied

Lessons Learned from Astrobee Operations on the International Space Station

Since its launch in 2019, NASA has been operating three Astrobee free-flying robots providing an autonomous and adaptable research platform aboard the International Space Station (ISS). These robots have not only facilitated a myriad of national and international research endeavors in microgravity but have also served as a STEM outreach platform for student competitions aboard the ISS. Amidst its extensive operational tenure, spanning over five years and exceeding 1200 hours of cumulative free-flyer operation as of April 2024, the Astrobee robots have encountered software and hardware anomalies. Despite its inherent design for on-orbit repair or replacement, certain anomalies have proven to be complex, necessitating remote resolution via software and firmware updates or, in extreme cases, hardware replacements or the return of faulty units to NASA's ground facilities for repair. Such challenges underscore the delicate balance between the autonomous functionality of Astrobee and the occasional need for human intervention to maintain optimal performance. One recurring point of failure identified during Astrobee's operational lifespan has been the SD card, a critical component utilized by the different Astrobee processors and the Dock Station. The occurrence of SD card anomalies, both on orbit and within ground units, has provided invaluable insights into the improvement of Astrobee's systems and mitigation to future faults. This presentation will focus on four key areas: 1. Overview of Faults and Anomalies: A comprehensive examination of the diverse array of faults and anomalies encountered by Astrobee and its associated systems both in orbit and on the ground. From software glitches to hardware malfunctions, this section provides insights into the challenges faced during Astrobee's operational tenure. 2. Resolution Processes and Procedures: An in-depth discussion of the methodologies and procedures implemented to resolve the encountered anomalies. This includes remote troubleshooting, software patches, firmware updates, and, when necessary, the logistics involved in hardware replacements or down-massing for repair. 3. Implementation of Software Updates and Hardware Upgrades: A detailed exploration of the strategies employed to mitigate the risk of recurring anomalies through the implementation of software updates and hardware upgrades. This section highlights the iterative nature of Astrobee's development, emphasizing the continuous pursuit of robustness and reliability. 4. Lessons Learned and Future Directions: Reflecting on the insights gained from addressing anomalies, this section examines the lessons learned and outlines future directions for enhancing Astrobee's robustness and resilience. It underscores the iterative nature of space exploration and the importance of adaptability and continuous improvement in the pursuit of scientific discovery. Through a nuanced examination of Astrobee's operational challenges and the strategies employed to overcome them, this presentation sheds light on the complexities of operating autonomous robotic systems in the ISS environment. It underscores NASA's commitment to pushing the boundaries of exploration and innovation while navigating the inherent challenges of space exploration.

Astrobee↗
NASA NTRS1975

Design of a modular digital computer system, CDRL no. D001, final design plan

The engineering breadboard implementation for the CDRL no. D001 modular digital computer system developed during design of the logic system was documented. This effort followed the architecture study completed and documented previously, and was intended to verify the concepts of a fault tolerant, automatically reconfigurable, modular version of the computer system conceived during the architecture study. The system has a microprogrammed 32 bit word length, general register architecture and an instruction set consisting of a subset of the IBM System 360 instruction set plus additional fault tolerance firmware. The following areas were covered: breadboard packaging, central control element, central processing element, memory, input/output processor, and maintenance/status panel and electronics.

Easton, R. A.↗
NASA NTRS1978

A versatile microprocessor-controlled hybrid receiver

A hybrid receiver has been designed for the Galileo Project. The receiver, located on the Galileo Orbiter, will autonomously acquire and track signals from the first atmospheric probe of Jupiter as well as demodulate, bit-synchronize, and buffer the telemetry data. The receiver has a conventional RF and LF front end but performs multiple functions digitally under firmware control. It will be a self-acquiring receiver that operates under a large frequency uncertainty; it can accommodate different modulation types, bit rates, and other parameter changes via reprogramming. A breadboard receiver and test set demonstrate a preliminary version of the sequential detection process and verify the hypothesis that a fading channel does not reduce the probability of detection.

Grant, T. L.↗
NASA NTRS1980

Prototype real-time baseband signal combiner

The design and performance of a prototype real-time baseband signal combiner, used to enhance the received Voyager 2 spacecraft signals during the Jupiter flyby, is described. Hardware delay paths, operating programs, and firmware are discussed.

Howard, L. D.↗
NASA NTRS1980

Prototype microprocessor controller

A microcomputer controller for STDN antennas was developed. The microcomputer technology reduces the system's physical size by the implementation in firmware of functions. The reduction in the number of components increases system reliability and similar benefit is derived when a graphic video display is substituted for several control and indicator panels. A substantial reduction in the number of cables, connectors, and mechanical switches is achieved. The microcomputer based system is programmed to perform calibration and diagnostics, to update the satellite orbital vector, and to communicate with other network systems. The design is applicable to antennas and lasers.

Zarur, J.↗
NASA NTRS1980

Data base systems in electronic design engineering

The concepts of an integrated design data base system (DBMS) as it might apply to an electronic design company are discussed. Data elements of documentation, project specifications, project tracking, firmware, software, electronic and mechanical design can be integrated and managed through a single DBMS. Combining the attributes of a DBMS data handler with specialized systems and functional data can provide users with maximum flexibility, reduced redundancy, and increased overall systems performance. Although some system overhead is lost due to redundancy in transitory data, it is believed the combination of the two data types is advisable rather than trying to do all data handling through a single DBMS.

Williams, D.↗
NASA NTRS1982

The Reed-Solomon encoders: Conventional versus Berlekamp's architecture

Concatenated coding was adopted for interplanetary space missions. Concatenated coding was employed with a convolutional inner code and a Reed-Solomon (RS) outer code for spacecraft telemetry. Conventional RS encoders are compared with those that incorporate two architectural features which approximately halve the number of multiplications of a set of fixed arguments by any RS codeword symbol. The fixed arguments and the RS symbols are taken from a nonbinary finite field. Each set of multiplications is bit-serially performed and completed during one (bit-serial) symbol shift. All firmware employed by conventional RS encoders is eliminated.

Perlman, M.↗
NASA NTRS1983

A study into the loss of lock of the space telescope fine guidance sensor

The results of a study into the loss of lock phenomenon associated with the Space Telescope Fine Guidance Sensor (FGS) are documented. The primary cause of loss of lock has been found to be a combination of cosmic ray spikes and photon noise due to a 14.5 Mv star. The probability of maintaining lock versus time is estimated both for the baseline FGS design and with parameter changes in the FGS firmware which will improve the probability of maintaining lock. The parameters varied are changeable in-flight from the ground and hence do not impact the design of the FGS hardware.

Polites, M. E.↗
NASA NTRS1984

Data reduction programs for a laser radar system

The listing and description of software routines which were used to analyze the analog data obtained from LIDAR - system are given. All routines are written in FORTRAN - IV on a HP - 1000/F minicomputer which serves as the heart of the data acquisition system for the LIDAR program. This particular system has 128 kilobytes of highspeed memory and is equipped with a Vector Instruction Set (VIS) firmware package, which is used in all the routines, to handle quick execution of different long loops. The system handles floating point arithmetic in hardware in order to enhance the speed of execution. This computer is a 2177 C/F series version of HP - 1000 RTE-IVB data acquisition computer system which is designed for real time data capture/analysis and disk/tape mass storage environment.

Badavi, F. F.↗
NASA NTRS1984

RTMPL: A structured programming and documentation utility for real-time multiprocessor simulations

The NASA Lewis Research Center is developing and evaluating experimental hardware and software systems to help meet future needs for real time simulations of air-breathing propulsion systems. The Real Time Multiprocessor Simulator (RTMPS) project is aimed at developing a prototype simulator system that uses multiple microprocessors to achieve the desired computing speed and accuracy at relatively low cost. Software utilities are being developed to provide engineering-level programming and interactive operation of the simulator. Two major software development efforts were undertaken in the RTMPS project. A real time multiprocessor operating system was developed to provide for interactive operation of the simulator. The second effort was aimed at developing a structured, high-level, engineering-oriented programming language and translator that would facilitate the programming of the simulator. The Real Time Multiprocessor Programming Language (RTMPL) allows the user to describe simulation tasks for each processor in a straight-forward, structured manner. The RTMPL utility acts as an assembly language programmer, translating the high-level simulation description into time-efficient assembly language code for the processors. The utility sets up all of the interfaces between the simulator hardware, firmware, and operating system.

Arpasi, D. J.↗
NASA NTRS1983

MST radar transmitter control and monitor system

A generalized transmitter control and monitor card was developed using the Intel 8031 (8051 family) microprocessor. The design was generalized so that this card can be utilized for virtually any control application with only firmware changes. The block diagram appears in Figure 2. The card provides for local control using a 16 key keypad (up to 64 keys are supported). The local display is four digits of 7 segment LEDs. The display can indicate the status of all major system parameters and provide voltage readout for the analog signal inputs. The card can be populated with only the chips required for a given application. Fully populated, the card has two RS-232 serial ports for computer communications. It has a total of 48 TTL parallel lines that can define as either inputs or outputs in groups of four. A total of 32 analog inputs with a 0-5 volt range are supported. In addition, a real-time clock/calendar is available if required. A total of 16 k bytes of ROM and 16 k bytes of RAM is available for programming. This card can be the basis of virtually any monitor or control system with appropriate software.

Brosnahan, J. W.↗