Results for “Firmware” — Page 5

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↗

DOE OSTI2023

Anomalous behavior detection by an artificial intelligence-enabled system with multiple correlated sensors

Multi-metric artificial intelligence (AI)/machine learning (ML) models for detection of anomalous behavior of a machine/system are disclosed. The multi-metric AI/ML models are configured to detect anomalous behavior of systems having multiple sensors that measure correlated sensor metrics such as coolant distribution units (CDUs). The multi-metric AI/ML models perform the anomalous system behavior detection in a manner that enables both a reduction in the amount of sensor instrumentation needed to monitor the system's operational behavior as well as a corresponding reduction in the complexity of the firmware that controls the sensor instrumentation. As such, AI-enabled systems and corresponding methods for anomalous behavior detection disclosed herein offer a technical solution to the technical problem of increased failure rates of existing multi-sensor systems, which is caused by the presence of redundant sensor instrumentation that necessitates complex firmware for controlling the sensor instrumentation.

Serebryakov, Sergey↗

DOE OSTI2020

Cybersecurity Methods for Grid-Connected Power Electronics

The present work shows a secure-by-design process, defense-in-depth method, and security techniques for a secure distributed energy resource. The distributed energy resource is a cybersecure, solar inverter and battery energy storage system prototype, collectively called the Cybersecure Power Router. Consideration is given to the use of the Smart Green Power Node for a foundation of the present work. Metrics for controller security are investigated to evaluate firmware security techniques. The prototype's ability to mitigate, respond to, and recover from firmware integrity degradation is examined. The prototype shows many working security techniques within the context of a grid-connected, distributed energy resource. Further work is expected in the Cybersecure Power Router project. Consideration is also provided for the migration of the present research and the Smart Green Power Node to realize a pre-production prototype.

Moquin, Stephen Joe↗

DOE OSTI2024

An Open-Source Framework for Rapid Validation of Scientific ASICs

Spacely is an open-source framework for the post-silicon validation of analog, digital, and mixed-signal ASICs (Application-Specific Integrated Circuits) which maximizes the reuse of hardware and software, reducing the time taken to achieve meaningful test results. Spacely specifically addresses the needs of small, flexible ASIC design teams commonly found in academia or research institutions which benefit most from sharing the overhead of test stand creation between many unique ASIC designs. Spacely is a set of software, firmware, and design practices. It targets two primary hardware platforms (NI-PXI and Caribou) as well as offering extensible support for bench instruments. Spacely provides a high-level Python interface to all test hardware for accessibility, while also giving more sophisticated teams the opportunity to integrate custom test firmware. The design principles of Spacely are presented, along with a demonstrative example of using Spacely to test a pixel detector readout ASIC.

46 INSTRUMENTATION RELATED TO NUCLEAR SCIENCE AND ↗

DOE OSTI2024

SCA Tools - SCRM Value Add or Lossy Noise Machines

Software supply chain risk management (SCRM) depends upon accurate information regarding the software components that comprise any given software system. The collection of components included in a software package can be organized within a software bill of materials, or SBOM. SBOMs are ideally generated when the software components are put together, such as at compile time, but for many reasons that has not and is not always possible. For example, legacy or proprietary software packages often do not have SBOMs available to downstream consumers of that software. It’s not just end users that are affected, manufacturers themselves also must deal with this problem. To answer these questions, the market has seen the rise of several commercial software composition analysis (SCA) tools. These tools aim to peer into completed software systems, automatically identifying hidden software dependencies and looking up known vulnerabilities associated with those dependencies to enable end-users to enhance their cyber supply chain risk management processes. These tools are potentially a huge boon to end users of legacy and proprietary software – and a potential bane, depending on how accurate they are. This research asks that question – how accurate are currently available binary SCA tools – and provides answers to several other questions: What does it mean to be “accurate”? What limitations do the tools have in identifying common edge cases that take place in modern software development? Can they help you avoid a devastating supply chain attack, or is it all just noise? After researching SCA tools on the market, we identified three vendors that fit our use case and would provide analysis on compiled binaries. Using these tools, we submitted firmware for critical infrastructure devices for analysis and SBOM generation. The SBOM outputs were then cross referenced with SBOMs generated through manual analysis for comparison. In addition to the firmware samples, we also submitted edge case samples based off a popular open-source library that were specifically crafted to evaluate each tools’ ability to accurately identify components. These samples were customized to be consistent with modifications we have seen in modern software development as well as a couple that are representative of supply chain attacks.

97 MATHEMATICS AND COMPUTING↗

DOE OSTI2025

Braxton Marlatt Intern Poster

The Internet of Things (IoT) encompasses a vast network of interconnected devices embedded with software, sensors, and network connectivity, enabling data collection and exchange. While IoT technology revolutionizes various industries, it also introduces significant security challenges. This research focuses on enhancing IoT security through the implementation of Zero Trust Architecture concepts, specifically targeting the Network and Device pillars of the Cybersecurity and Infrastructure Security Agency’s Zero Trust Maturity Model. By generating Codified Attack Surfaces (CAS) using custom Structured Threat Information eXpression bundles, this project aims to provide enhanced visibility into network communications, detect vulnerabilities in device firmware, and improve the overall security posture for IoT devices and networks. The methodology involves defining custom STIX schema and objects, collecting data from intra-IoT traffic, external network traffic, and firmware analysis, and automating the conversion and correlation of this data into STIX bundles. The automated generation of attack surfaces offers comprehensive insights into activity, vulnerabilities, and anomalies within an IoT environment, enabling proactive threat identification and mitigation.

24 - POWER TRANSMISSION AND DISTRIBUTION↗

DOE OSTI2024

Evaluating Methods of Software Bill of Materials Generation to Enhance Nuclear Power Plant Cybersecurity

Instrumentation and control (I&C) systems in nuclear power plants (NPPs) are potential targets of cyberattacks and can prove deleterious for the safety of the NPPs. A Software Bill of Materials (SBOM) provides a detailed list of the various components and their dependencies in software, which helps in vulnerability and risk assessment for cyber hygiene and situational awareness. For an NPP, the process of generating an accurate SBOM report can be complex due to the legacy systems and firmware binaries involved. While most current SBOM tools are focused more on modern internet technology software, this research provides insights and guidelines for an NPP to generate an accurate and efficient SBOM. Here, the paper proposes a new methodology to help NPPs categorize software and use appropriate tools to generate SBOMs for their digital I&C systems.

SBOM↗

DOE OSTI2021

A Review of Cyber-Physical Security for Photovoltaic Systems

In this paper, the challenges and a future vision of the cyber-physical security of photovoltaic (PV) systems are discussed from a firmware, network, PV converter controls, and grid security perspective. The vulnerabilities of PV systems are investigated under a variety of cyber-attacks, ranging from data integrity attacks to software-based attacks. A success rate metric is designed to evaluate the impact and facilitate decision making. Model-based and data-driven methods for threat detection and mitigation are summarized. In addition, the blockchain technology that addresses cyber-attacks in software and cyber networks is described. Simulation and experimental results that show the impact of cyber-attacks at the converter (device) and grid (system) levels are presented. Finally, potential research opportunities are discussed for next-generation, cyber-secure power electronics systems. These opportunities include multi-scale controllability, self-/event-triggering control, artificial intelligence/machine learning, hot patching, and online security. As of today, this study will be one of the few comprehensive studies in this emerging and fast-growing area.

14 SOLAR ENERGY↗

DOE OSTI2024

End-to-end codesign of Hessian-aware quantized neural networks for FPGAs

Here, we develop an end-to-end workflow for the training and implementation of co-designed neural networks (NNs) for efficient field-programmable gate array (FPGA) hardware. Our approach leverages Hessian-aware quantization of NNs, the Quantized Open Neural Network Exchange intermediate representation, and the hls4ml tool flow for transpiling NNs into FPGA firmware. This makes efficient NN implementations in hardware accessible to nonexperts in a single open sourced workflow that can be deployed for real-time machine-learning applications in a wide range of scientific and industrial settings. We demonstrate the workflow in a particle physics application involving trigger decisions that must operate at the 40-MHz collision rate of the CERN Large Hadron Collider (LHC). Given the high collision rate, all data processing must be implemented on FPGA hardware within the strict area and latency requirements. Based on these constraints, we implement an optimized mixed-precision NN classifier for high-momentum particle jets in simulated LHC proton-proton collisions.

47 OTHER INSTRUMENTATION↗

DOE OSTI2021

Structured Threat Intelligence Graph Case Studies and Use

Brief into to the GMLC Firmware Command and Control project and NREL's work on that project.

firmware analysis↗

DOE OSTI2021

JTAG-based PLC memory acquisition framework for industrial control systems

In industrial control systems (ICS), programmable logic controllers (PLC) are the embedded devices that directly control and monitor critical industrial infrastructure processes such as nuclear plants and power grid stations. Cyberattacks often target PLCs to sabotage a physical process. A memory forensic analysis of a suspect PLC can answer questions about an attack, including compromised firmware and manipulation of PLC control logic code and I/O devices. Given physical access to a PLC, collecting forensic information from the PLC memory at the hardware-level is risky and challenging. It may cause the PLC to crash or hang since PLCs have proprietary, legacy hardware with heterogeneous architecture. This paper addresses this research problem and proposes a novel JTAG (Joint Test Action Group)-based framework, Kyros, for reliable PLC memory acquisition. Kyros systematically creates a JTAG profile of a PLC through hardware assessment, JTAG pins identification, memory map creation, and optimizing acquisition parameters. It also facilitates the community of interest (such as ICS owners, operators, and vendors) to develop the JTAG profiles of PLCs. Further, we present a case study of Kyros implementation over Allen-Bradley 1756-A10/B to help understand the framework's application on a real-world PLC used in industry settings. The sample PLC memory dumps are shared with the research community to facilitate further research.

Rais, Muhammad Haris↗

DOE OSTI2020

The CLAS12 Trigger System

This article describes the CLAS12 Trigger System. The simulation, hardware, and software design, as well as all validation procedures, are discussed here. The firmware development tools used are discussed as well, including our experience with VIVADO High Level Synthesis.

46 INSTRUMENTATION RELATED TO NUCLEAR SCIENCE AND ↗

DOE OSTI2022

Rate-capability of the VMM3a front-end in the RD51 Scalable Readout System

The VMM3a is an Application Specific Integrated Circuit (ASIC), specifically developed for the readout of gaseous detectors. Originally developed within the ATLAS New Small Wheel (NSW) upgrade, it has been successfully integrated into the Scalable Readout System (SRS) of the RD51 collaboration. This allows, to use the VMM3a also in small laboratory set-ups and mid-scale experiments, which make use of Micro-Pattern Gaseous Detectors (MPGDs). As part of the integration of the VMM3a into the SRS, the readout and data transfer scheme was optimised to reach a high rate-capability of the entire readout system and profit from the VMM3a's high single-channel rate-capability of 3.6Mhits/s. The optimisation focused mainly on the handling of the data output stream of the VMM3a, but also on the development of a trigger-logic between the front-end cards and the DAQ computer. In this article, two firmware implementations of the non-ATLAS continuous readout mode are presented, as well as the implementation of the trigger-logic. Afterwards, a short overview on X-ray imaging results is presented, to illustrate the high rate-capability from an application point-of-view.

72 PHYSICS OF ELEMENTARY PARTICLES AND FIELDS↗

DOE OSTI2022

Development and test of a mini-Data Acquisition system for the High-Luminosity LHC upgrade of the ATLAS Monitored Drift Tube detector

New front-end electronics including ASICs and FPGA boards are under development for the ATLAS Monitored Drift Tube (MDT) detector to handle the large data rates and harsh environment expected at high-luminosity LHC runs. A mobile Data Acquisition (miniDAQ) system is designed to perform integration tests of these front-end electronics. In addition, it will be used for surface commissioning of 96 small-radius MDT (sMDT) chambers and for integration and commissioning of new front-end electronics on the present ATLAS MDT chambers. Details of the miniDAQ hardware and firmware are described in this article. Here, the miniDAQ system is also used to read out new front-end electronics on an sMDT prototype chamber using cosmic muons and results obtained are shown.

46 INSTRUMENTATION RELATED TO NUCLEAR SCIENCE AND ↗

DOE OSTI2025

Design and commissioning of readout electronics for a $K$$^{0}_{L}$ and $μ$ detector at the Belle II experiment

The K-long and muon detector (KLM) constitutes the outer-most volume of the Belle II spectrometer at the interaction region of the SuperKEKB collider in Tsukuba, Japan. The KLM detector was partially upgraded since the Belle experiment by replacing many of its resistive-plate chambers with scintillators containing wavelength-shifting fibers and instrumenting it with silicon photomultipliers. Here, we describe the readout electronics, firmware, and software created to control and acquire data from the scintillators and resistive-plate chambers.

Belle II↗