Results for “HARDWARE” — Page 6

NASA NTRS2018

Digital Proxy Simulation of Robotic Hardware

A computer-implemented method, computer program product, and computing system is provided for a digital proxy simulation of robotic hardware. In an implementation, a method may include creating a digital proxy simulation for a robotic hardware wherein the digital simulation and the robotic hardware may share a network interface. a user may be provided with an option to switch between the robotic hardware and the digital proxy simulation. The switch may be executed, upon receiving a user selection, between the robotic hardware and the digital proxy simulation, wherein executing the switch includes transferring input and output signals between the digital proxy simulation and the robotic hardware.

Bacon, James A.↗

NASA NTRSDate not supplied

The Ejectable Data Recorder: A Lean, Risk-Informed Approach for Hardware Development

NASA is developing the Orion spacecraft to transport crew from the Earth to the Moon as part of the Artemis series of missions. To provide a crew escape capability from pre-launch through ascent, the Orion vehicle is equipped with a Launch Abort System (LAS), built by Lockheed Martin, which pulls the capsule away from the launch vehicle in the event of an abort scenario. The Ascent Abort 2 (AA-2) test flight occurred on July 2, 2019,and tested a production version of the LAS to ensure that it can operate as intended, and to collect a large data set from hundreds of sensors on the vehicle to support Orion flight certification. In the original AA-2 architecture, a single-string set of communications antennas on the LAS would downlink all of the in-flight test data to ground stations. However, that communications architecture was predicted to have data dropouts during abort and jettison of the LAS, and would not support data transmission at all after LAS jettison. As a result, a comprehensive trade study was completed, yielding the addition of antennas on the crew module (CM), a buffer/rebroadcast capability for key portions of the flight, and an ejectable data recorder (EDR) subsystem. This EDR subsystem would serve as a backup to the radio frequency (RF) communications system, and would be non-flight critical, providing a unique capability that enabled management to take a different approach with the hardware and software development. The Crew Module and Separation Ring were developed as “Class 1”Flight Hardware, albeit with some tailoring approaches to enable efficiencies. The Class 1 designation requires full rigor for flight hardware and software, documenting everything that happens to a piece of hardware from procurement through disposal, requiring a full spectrum of acceptance tests, and the highest rigor of quality assurance processes. At the other end of the spectrum, Class 3hardware is controlled, but not intended for flight, and leaves the level of rigor up to the project manager. This classification is often used for research and development projects. Similarly,Class-1E has been recently defined at NASA for ISS payloads and technology development projects that are not flight critical and do not need the full rigor of Class 1 to be successful. The EDR subsystem was challenged at commencement to adopt a skunkworks and agile-like approach to hardware development, allowing for a different risk posture than the rest of the AA-2 hardware. After initially pursuing Class 1 processes, the EDR subsystem design evolved to incorporating numerous commercial components, leading to re-designation as a Class-1E subsystem. The resulting EDR subsystem was fully successful in meeting all flight system requirements, and achieved 100% retrieval of flight test data. This paper will discuss the risk posture of the EDR subsystem and the subsequent tailoring that was enacted as part of its Class-1E status.

EDR↗

NASA NTRS2018

Mission Summary of Cassini Spacecraft Guidance and Control Hardware Health and Performance

The Cassini-Huygens mission ended on September 15, 2017, after nearly two decades in ight. The well-designed Cassini spacecraft had robust hardware that permitted two extended missions, lasting nine years longer than the expected prime mission. At the end of the mission, the Attitude and Articulation Control Subsystem (AACS) was using two pieces of redundant back-up of hardware, one reaction wheel and the hydrazine thruster branch, due to hardware anomalies earlier in the mission. The back-up hardware performed nominally through the rest of mission. The prime reaction wheels at the end of the mission had reached more than 130% of the consumable limit for number of revolutions. No thruster on either thruster branch accumulated more than 45% of the consumable limits. The inertial reference unit slightly exceeded the pre-launch requirements on bias error, but as the software continuously estimated this value in ight, the attitude estimation was not adversely a ected. The star trackers performed nominally, and though there was a spacecraft anomaly in 1998 related to the star trackers, the origin was not in hardware itself. The Sun sensors and accelerometer both performed as expected and met all requirements throughout the mission. Ultimately, the lifetime of the Cassini spacecraft was not limited by hardware performance. Planetary protection requirements necessitated the end of the mission as the spacecraft's propellant reserves depleted, and Cassini plunged into Saturn's atmosphere with a healthy attitude control system.

Stupik, Joan↗

NASA NTRS2019

Integration of analyses in an EMC control plan for avionics hardware in space applications

An EMC Control Plan is a very valuable tool for outlining the processes needed to suppress EMI and provide EMC for the avionics hardware used in space applications. The EMC Control Plan provides guidance to EMC engineers and avionics hardware designers on methods, procedures, and practices to achieve optimum EMC. The design of an EMC Control Plan for space avionics requires unique challenges due to the nature of the space missions and the space environment. An EMC Control Plan for avionics hardware in space applications can be optimized by the integration of reliability and margin analyses that are uniquely suitable to space applications and avionics hardware. The paper provides a description of the analyses and the rationale for the inclusion of such analyses in the EMC Control Plan, including some examples. The paper concludes by providing a detailed outlined of an EMC Control Plan for avionics hardware in space applications and how this approach fits well with the overall avionics hardware design and development cycle.

Perez, Reinaldo↗

NASA NTRSDate not supplied

Comparing the Electrical Modeling and Thermal Analysis Toolbox Simulation Data to Electrified Aircraft Propulsion Test Hardware Data

A model using the Electrical Modeling and Thermal Analysis Toolbox (EMTAT), a National Aeronautics and Space Administration (NASA)-developed Simulink® model block library of electrical components, was developed to mirror the Hybrid Propulsion Emulation Rig (HyPER) hardware, a laboratory focused on Electrified Aircraft Propulsion (EAP) hardware tests. The goal of the model was to demonstrate the utility of the library by comparing the accuracy of the library models to the performance of real hardware, with the primary metrics being the simulation outputs matching physical test hardware data within 5% of full scale.The objective of this paper is to present the background, setup, testing and results of this comparison. It describes some of the adjustments that were necessary to match the system hardware, as well as next steps in verification and validation. The outputs of the model were compared to the results of several tests in HyPER, and in the process captured an additional torque loss that is still being analyzed for the root cause but has been confirmed in the hardware. Across all the test series, only one key model parameter was outside the target 5% full scale matching, and nearly 70% were within 1%.

Mark E Bell↗

NASA NTRS2020

Hardware Verification and Validation for a Navigation Sensor Software Model in Support of Flight Vehicle Performance Analysis

… or, “It’s in the details, how to make complicated software perform like complicated hardware.” In attempts to minimize development time and quickly build an operational vehicle, NASA’s Space Launch System (SLS) has had to be intentional about integrated testing. Constraints on budget and schedule have required balance between testing needs and the desire for an integrated flight vehicle as soon as possible. To provide key insights early in design and analysis cycles, a large amount of effort has shifted into maturing and validating models at the component level with integrated testing as a means to validate their integration. In terms of SLS Navigation, this, and the model-based design approach have pushed explicit requirements for sensor models to be validated against flight hardware to high precision. This paper covers the approach taken to verify and validate the models for the two key navigation sensors on the SLS vehicle, the Redundant Inertial Navigation Sensor and the Rate Gyro Assembly. These models are used in performance evaluation, fault detection, and operations development extensively. Using a mix of data from hardware vendor documentation and testing reports, limited in-house testing, and integration activities, these models were able to be validated against flight hardware at multiple levels, from the internal software design to statistical behavior at the raw sensor and integrated box levels. The high level of insight into the hardware elements is instrumental to support flight certification activities and building confidence in SLS Navigation capability. Focused testing enabled additional insight and validation that proved invaluable and the resulting insights were used to focus and mature models. Additionally, of having validated performance-based hardware models enables a wide breadth of activities including detailed fault detection studies and integration into future vehicle frameworks, such as an upper stage and provide a valuable asset to continued SLS analysis and design.

Evan J Anzalone↗

NASA NTRS2020

Hardware Verification and Validation for a Navigation Sensor Software Model in Support of Flight Vehicle Performance Analysis

… or, “It’s in the details, how to make complicated software perform like complicated hardware.” In attempts to minimize development time and quickly build an operational vehicle, NASA’s Space Launch System (SLS) has had to be intentional about integrated testing. Constraints on budget and schedule have required balance between testing needs and the desire for an integrated flight vehicle as soon as possible. To provide key insights early in design and analysis cycles, a large amount of effort has shifted into maturing and validating models at the component level with integrated testing as a means to validate their integration. In terms of SLS Navigation, this, and the model-based design approach have pushed explicit requirements for sensor models to be validated against flight hardware to high precision. This paper covers the approach taken to verify and validate the models for the two key navigation sensors on the SLS vehicle, the Redundant Inertial Navigation Sensor and the Rate Gyro Assembly. These models are used in performance evaluation, fault detection, and operations development extensively. Using a mix of data from hardware vendor documentation and testing reports, limited in-house testing, and integration activities, these models were able to be validated against flight hardware at multiple levels, from the internal software design to statistical behavior at the raw sensor and integrated box levels. The high level of insight into the hardware elements is instrumental to support flight certification activities and building confidence in SLS Navigation capability. Focused testing enabled additional insight and validation that proved invaluable and the resulting insights were used to focus and mature models. Additionally, of having validated performance-based hardware models enables a wide breadth of activities including detailed fault detection studies and integration into future vehicle frameworks, such as an upper stage and provide a valuable asset to continued SLS analysis and design.

Thomas Park↗

NASA NTRS2023

Comparing the Electrical Modeling and Thermal Analysis Toolbox Simulation Data to Electrified Aircraft Propulsion Test Hardware Data

A model using the Electrical Modeling and Thermal Analysis Toolbox (EMTAT), a National Aeronautics and Space Administration (NASA)-developed Simulink® model block library of electrical components, was developed to mirror the Hybrid Propulsion Emulation Rig (HyPER) hardware, a laboratory focused on Electrified Aircraft Propulsion (EAP) hardware tests. The goal of the model was to demonstrate the utility of the library by comparing the accuracy of the library models to the performance of real hardware, with the primary metrics being the simulation outputs matching physical test hardware data within 5 percent of full scale. The objective of this paper is to present the background, setup, testing and results of this comparison. It describes some of the adjustments that were necessary to match the system hardware, as well as next steps in verification and validation. The outputs of the model were compared to the results of several tests in HyPER, and in the process captured an additional torque loss that is still being analyzed for the root cause but has been confirmed in the hardware. Across all the test series, only one key model parameter was outside the target 5 percent full scale matching, and nearly 70 percent were within 1 percent.

Mark E. Bell↗

NASA NTRSDate not supplied

NASA Exploration Toilet Hardware Status and Crew Feedback from ISS Artemis-2 Demonstration

The Universal Waste Management System (UWMS), ISS operational nomenclature “Toilet”, was initially installed on the International Space Station (ISS) in 2020 with final installation completed in 2021. Technical progress continues to be made with each on-orbit operation and will ultimately culminate with nominal US crew use of the hardware on ISS. During 2023, the Artemis-2 Demonstration was started, and this paper discusses issues encountered, on-orbit troubleshooting, subsequent ground failure investigation and proposed repairs as well as near-term plans to resume the Artemis-2 demo. Also discussed is an update to the commercial-off-the-shelf (COTS) Conductivity Monitor which is planned to be flown for the resumption of the demo along with additional UWMS hardware and Toilet Integration Hardware (TIH). An updated design of the commode seat and fecal bag for Artemis-2 UWMS will be demonstrated on ISS and a summary of the hardware is included in the paper. Use of the hardware during the first days of the aborted demonstration by crewmembers and feedback received is summarized as well as hardware updates resulting from that feedback. The paper will also provide an overview of the demo results to date that inform the Orion-installed UWMS unit and future manifesting of consumables for both Orion and ISS.

Toilet↗

NASA NTRSDate not supplied

NASA Exploration Toilet Hardware Status and Crew Feedback from ISS Artemis-2 Demonstration

The Universal Waste Management System (UWMS), ISS operational nomenclature “Toilet”, was initially installed on the International Space Station (ISS) in 2020 with final installation completed in 2021. Technical progress continues to be made with each on-orbit operation and will ultimately culminate with nominal US crew use of the hardware on ISS. During 2023, the Artemis-2 Demonstration was started, and this paper discusses issues encountered, on-orbit troubleshooting, subsequent ground failure investigation and proposed repairs as well as near-term plans to resume the Artemis-2 demo. Also discussed is an update to the commercial-off-the-shelf (COTS) Conductivity Monitor (CCM) which is planned to be flown for the resumption of the demo along with additional UWMS hardware and Toilet Integration Hardware (TIH). An updated design of the commode seat and fecal bag for Artemis-2 UWMS will be demonstrated on ISS and a summary of the hardware is included in the paper. Use of the hardware during the first days of the aborted demonstration by crewmembers and feedback received is summarized as well as hardware updates resulting from that feedback. The paper will also provide an overview of the demo results to date that inform the Orion-installed UWMS unit and future manifesting of consumables for both Orion and ISS.

Toilet↗

NASA NTRSDate not supplied

NASA Exploration Hardware Status and Crew Feedback from Artemis-2 Demonstration

The Universal Waste Management System (UWMS), ISS operational nomenclature “Toilet”, was initially installed on the International Space Station (ISS) in 2020 with final installation completed in 2021. Technical progress continues to be made with each on-orbit operation and will ultimately culminate with nominal US crew use of the hardware on ISS. During 2023, the Artemis-2 Demonstration was started, and this paper discusses issues encountered, on-orbit troubleshooting, subsequent ground failure investigation and proposed repairs as well as near-term plans to resume the Artemis-2 demo. Also discussed is an update to the commercial-off-the-shelf (COTS) Conductivity Monitor which is planned to be flown for the resumption of the demo along with additional UWMS hardware and Toilet Integration Hardware (TIH). An updated design of the commode seat and fecal bag for Artemis-2 UWMS will be demonstrated on ISS and a summary of the hardware is included in the paper. Use of the hardware during the first days of the aborted demonstration by crewmembers and feedback received is summarized as well as hardware updates resulting from that feedback. The paper will also provide an overview of the demo results to date that inform the Orion-installed UWMS unit and future manifesting of consumables for both Orion and ISS.

Toilet↗

DOE OSTI2016

Generating clock signals for a cycle accurate, cycle reproducible FPGA based hardware accelerator

A method, system and computer program product are disclosed for generating clock signals for a cycle accurate FPGA based hardware accelerator used to simulate operations of a device-under-test (DUT). In one embodiment, the DUT includes multiple device clocks generating multiple device clock signals at multiple frequencies and at a defined frequency ratio; and the FPG hardware accelerator includes multiple accelerator clocks generating multiple accelerator clock signals to operate the FPGA hardware accelerator to simulate the operations of the DUT. In one embodiment, operations of the DUT are mapped to the FPGA hardware accelerator, and the accelerator clock signals are generated at multiple frequencies and at the defined frequency ratio of the frequencies of the multiple device clocks, to maintain cycle accuracy between the DUT and the FPGA hardware accelerator. In an embodiment, the FPGA hardware accelerator may be used to control the frequencies of the multiple device clocks.

97 MATHEMATICS AND COMPUTING↗

DOE OSTI2018

Data to hardware binding with physical unclonable functions

The various technologies presented herein relate to binding data (e.g., software) to hardware, wherein the hardware is to utilize the data. The generated binding can be utilized to detect whether at least one of the hardware or the data has been modified between an initial moment (enrollment) and a later moment (authentication). During enrollment, an enrollment value is generated that includes a signature of the data, a first response from a PUF located on the hardware, and a code word. During authentication, a second response from the PUF is utilized to authenticate any of the content in the enrollment value, and based upon the authentication, a determination can be made regarding whether the hardware and/or the data have been modified. If modification is detected then a mitigating operation can be performed, e.g., the hardware is prevented from utilizing the data. If no modification is detected, the data can be utilized.

97 MATHEMATICS AND COMPUTING↗

DOE OSTI2019

Generating clock signals for a cycle accurate, cycle reproducible FPGA based hardware accelerator

A method, system and computer program product are disclosed for generating clock signals for a cycle accurate FPGA based hardware accelerator used to simulate operations of a device-under-test (DUT). In one embodiment, the DUT includes multiple device clocks generating multiple device clock signals at multiple frequencies and at a defined frequency ratio; and the FPG hardware accelerator includes multiple accelerator clocks generating multiple accelerator clock signals to operate the FPGA hardware accelerator to simulate the operations of the DUT. In one embodiment, operations of the DUT are mapped to the FPGA hardware accelerator, and the accelerator clock signals are generated at multiple frequencies and at the defined frequency ratio of the frequencies of the multiple device clocks, to maintain cycle accuracy between the DUT and the FPGA hardware accelerator. In an embodiment, the FPGA hardware accelerator may be used to control the frequencies of the multiple device clocks.

Asaad, Sameh W.↗

DOE OSTI2020

On-the fly scheduling of execution of dynamic hardware behaviors

Methods for dynamically executing computer code across multiple disparate processing unit architectures are disclosed. During execution of a first portion of computer code on a first processing unit, it is determined that a first dynamic hardware behavior of a plurality of dynamic hardware behaviors will occur at a subsequent point in time, based on a second dynamic hardware behavior that is occurring. The methods include determining to execute code corresponding to the first dynamic hardware behavior on a second processing unit, rather than the first processing unit, and scheduling computer program code corresponding to the first dynamic hardware behavior to execute on the second processing unit rather than the first processing unit. Upon completion of execution of the computer code corresponding to the first dynamic hardware behavior, a remaining portion of the computer code is scheduled to execute on the first processing unit.

97 MATHEMATICS AND COMPUTING↗

DOE OSTI2021

Generating clock signals for a cycle accurate, cycle reproducible FPGA based hardware accelerator

A method, system and computer program product are disclosed for generating clock signals for a cycle accurate FPGA based hardware accelerator used to simulate operations of a device-under-test (DUT). In one embodiment, the DUT includes multiple device clocks generating multiple device clock signals at multiple frequencies and at a defined frequency ratio; and the FPG hardware accelerator includes multiple accelerator clocks generating multiple accelerator clock signals to operate the FPGA hardware accelerator to simulate the operations of the DUT. In one embodiment, operations of the DUT are mapped to the FPGA hardware accelerator, and the accelerator clock signals are generated at multiple frequencies and at the defined frequency ratio of the frequencies of the multiple device clocks, to maintain cycle accuracy between the DUT and the FPGA hardware accelerator. In an embodiment, the FPGA hardware accelerator may be used to control the frequencies of the multiple device clocks.

Asaad, Sameh W.↗

DOE OSTI2024

PRISTINE: An Emulation Platform for PCB-Level Hardware Trojans

Printed circuit Boards (PCBs) are becoming increasingly vulnerable to malicious design alteration, also known as Trojan attacks, due to a distributed business model that often involves various untrusted parties. Such attacks can be mounted at various stages in the PCB life cycle. The relative ease of alteration of PCB hardware even after fabrication (due to physical access to surface-mounted critical components and traces) makes them attractive for an adversary to manipulate their functional/physical behavior for malicious intent. There is a growing need to explore viable Trojan attacks in a PCB, analyze their functional and physical characteristics (e.g., impact on power or delay), and study the effectiveness of countermeasures against these attacks. While simulation-based approaches for PCB Trojan insertion are effective at creating a large population of possible Trojans, they fail to provide functional feasibility analysis with a realistic workload for a trigger circuit. Also, they cannot estimate a Trojan’s side-channel footprint due to the unavailability of physical models of diverse PCB components. To address these deficiencies, in this paper, we present PRISTINE, a PCB-level emulation system for any integrity or physical tampering issues, specifically, hardware Trojan insertion. The need for building such an emulation platform to resolve PCB trust issues in the supply chain is also surveyed and discussed. Both custom Hardware Hacking (HaHa) boards and multiple commercial PCBs are then used to test the ability of the proposed system to emulate various hardware Trojans specially designed to exploit board-specific hardware characteristics. Experimental results on emulated board-level Trojans show that a wide range of Trojans can be successfully activated, thus enabling the expected payload effects on both types of boards to be studied and quantified. The resulting data are further analyzed to create PCB-level Trojan benchmarks. In particular, a comparative evaluation of the experimental results is used to propose a risk level metric that quantifies the probability of detection and degree of payload impact of each Trojan on a given commercial PCB.

47 OTHER INSTRUMENTATION↗

DOE OSTI2017

Traleika Glacier: A hardware-software co-designed approach to exascale computing

The move from current petascale machines to future exascale machines will need both hardware improvements and software changes. Hardware will need to evolve to focus primarily on features that lower energy consumption: near-threshold voltage operation, fine-grained power and clock management and heterogeneity. Software will also need to evolve and be able to express more parallelism, become more dynamic and adaptable in order to be able to operate on a much more variable hardware. Here, we present Traleika Glacier, an effort that seeks to evaluate radical design changes to meet the constraints, both in terms of power and cost, of exascale computing. The salient features of the hardware design presented in the work include a) a use of heterogeneous cores, b) a redesign of the memory system that centers around hierarchical scratchpads and a global address space, c) the hardware acceleration of certain memory and network operations through specialized engines and, d) very fine-grained control and monitoring capabilities. On the software side, we describe a task-based runtime system, the Open Community Runtime (OCR) which aims to express a wide range of higher-level programming models with a very limited set of core concepts: event-driven tasks for computation, events for synchronization and relocatable data-blocks for data management.

97 MATHEMATICS AND COMPUTING↗