Search NASA⌕ Search

SEARCH · Search NASA

Results for “Embedded 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.

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

At least 109 records · Page 6
All sourcesNASA NTRSDOE OSTI
NASA NTRS1989

Initial flight qualification and operational maintenance of X-29A flight software

This paper is predominantly a nontechnical discussion of some significant aspects of the initial flight qualification and operational maintenance of the flight control system software for the X-29A technology demonstrator. Flight qualification and maintenance of complex, embedded flight control system software poses unique problems. The X-29A technology demonstrator aircraft has a digital flight control system which incorporates functions generally considered too complex for analog systems. Organizational responsibilities, software assurance issues, tools, and facilities are discussed.

Earls, Michael R.↗
NASA NTRS1987

EOS: A project to investigate the design and construction of real-time distributed Embedded Operating Systems

Project EOS is studying the problems of building adaptable real-time embedded operating systems for the scientific missions of NASA. Choices (A Class Hierarchical Open Interface for Custom Embedded Systems) is an operating system designed and built by Project EOS to address the following specific issues: the software architecture for adaptable embedded parallel operating systems, the achievement of high-performance and real-time operation, the simplification of interprocess communications, the isolation of operating system mechanisms from one another, and the separation of mechanisms from policy decisions. Choices is written in C++ and runs on a ten processor Encore Multimax. The system is intended for use in constructing specialized computer applications and research on advanced operating system features including fault tolerance and parallelism.

Campbell, R. H.↗
NASA NTRS2013

The Evolution of Software and Its Impact on Complex System Design in Robotic Spacecraft Embedded Systems

The growth in computer hardware performance, coupled with reduced energy requirements, has led to a rapid expansion of the resources available to software systems, driving them towards greater logical abstraction, flexibility, and complexity. This shift in focus from compacting functionality into a limited field towards developing layered, multi-state architectures in a grand field has both driven and been driven by the history of embedded processor design in the robotic spacecraft industry.The combinatorial growth of interprocess conditions is accompanied by benefits (concurrent development, situational autonomy, and evolution of goals) and drawbacks (late integration, non-deterministic interactions, and multifaceted anomalies) in achieving mission success, as illustrated by the case of the Mars Reconnaissance Orbiter. Approaches to optimizing the benefits while mitigating the drawbacks have taken the form of the formalization of requirements, modular design practices, extensive system simulation, and spacecraft data trend analysis. The growth of hardware capability and software complexity can be expected to continue, with future directions including stackable commodity subsystems, computer-generated algorithms, runtime reconfigurable processors, and greater autonomy.

software↗
NASA NTRS2007

Arbitrating Control of Control and Display Units

The ARINC 739 Switch is a computer program that arbitrates control of two multi-function control and display units (MCDUs) between (1) a commercial flight-management computer (FMC) and (2) NASA software used in research on transport aircraft. (MCDUs are the primary interfaces between pilots and FMCs on many commercial aircraft.) This program was recently redesigned into a software library that can be embedded in research application programs. As part of the redesign, this software was combined with software for creating custom pages of information to be displayed on a CDU. This software commands independent switching of the left (pilot s) and right (copilot s) MCDUs. For example, a custom CDU page can control the left CDU while the FMC controls the right CDU. The software uses menu keys to switch control of the CDU between the FMC or a custom CDU page. The software provides an interface that enables custom CDU pages to insert keystrokes into the FMC s CDU input interface. This feature allows the custom CDU pages to manipulate the FMC as if it were a pilot.

Sugden, Paul C.↗
DOE OSTI2021

Enabling Interoperable SCADA Communications for PV Inverters through Embedded Controllers

The percentage integration of photovoltaic (PV) inverters in the field has increased significantly in the past 5 years. Regardless of the size of the PV plants and the inverters (residential vs. commercial), it is becoming crucial that these devices have the capability to communicate with peers (other smart devices) and with components that are at a hierarchy above the inverters (e.g., supervisory control and data acquisition (SCADA) systems, distributed controllers, and data managers). This project aims to develop a standard SCADA software code for inverters’ embedded controllers that will enable interoperability with other components in the system. To achieve this, the code will be developed using two different protocols: Distributed Network Protocol 3 and International Electrotechnical Commission 61850. The developed code is aimed to be deployed in simple embedded controllers. It will be tested in the National Renewable Energy Laboratory’s (NREL’s) Energy Systems Integration Facility. The tested code will then be made available through Triangle MicroWorks’s (TMW’s) software platform. The primary objectives of this project include training the NREL team with TMW’s embedded controller libraries, developing an interoperable communication code for embedded controllers, successfully testing and deploying the code, and demonstrating the newly developed code in a conference.

14 SOLAR ENERGY↗
NASA NTRS1989

Initial flight qualification and operational maintenance of X-29A flight software

A discussion is presented of some significant aspects of the initial flight qualification and operational maintenance of the flight control system softward for the X-29A technology demonstrator. Flight qualification and maintenance of complex, embedded flight control system software poses unique problems. The X-29A technology demonstrator aircraft has a digital flight control system which incorporates functions generally considered too complex for analog systems. Organizational responsibilities, software assurance issues, tools, and facilities are discussed.

Earls, Michael R.↗
NASA NTRS1998

Real-Time Sensor Validation System Developed

Real-time sensor validation improves process monitoring and control system dependability by ensuring data integrity through automated detection of sensor data failures. The NASA Lewis Research Center, Expert Microsystems, and Intelligent Software Associates have developed an innovative sensor validation system that can automatically detect automated sensor failures in real-time for all types of mission-critical systems. This system consists of a sensor validation network development system and a real-time kernel. The network development system provides tools that enable systems engineers to automatically generate software that can be embedded within an application. The sensor validation methodology captured by these tools can be scaled to validate any number of sensors, and permits users to specify system sensitivity. The resulting software reliably detects all types of sensor data failures.

Zakrajsek, June F.↗
NASA NTRS2011

Sptrace

Sptrace is a general-purpose space utilization tracing system that is conceptually similar to the commercial Purify product used to detect leaks and other memory usage errors. It is designed to monitor space utilization in any sort of heap, i.e., a region of data storage on some device (nominally memory; possibly shared and possibly persistent) with a flat address space. This software can trace usage of shared and/or non-volatile storage in addition to private RAM (random access memory). Sptrace is implemented as a set of C function calls that are invoked from within the software that is being examined. The function calls fall into two broad classes: (1) functions that are embedded within the heap management software [e.g., JPL's SDR (Simple Data Recorder) and PSM (Personal Space Management) systems] to enable heap usage analysis by populating a virtual time-sequenced log of usage activity, and (2) reporting functions that are embedded within the application program whose behavior is suspect. For ease of use, these functions may be wrapped privately inside public functions offered by the heap management software. Sptrace can be used for VxWorks or RTEMS realtime systems as easily as for Linux or OS/X systems.

Burleigh, Scott C.↗
NASA NTRS2017

Earth Global Reference Atmospheric Model (Earth-GRAM) GRAM Virtual Meeting

What is Earth-GRAM? Provide monthly mean and standard deviation for any point in atmosphere; Monthly, Geographic, and Altitude Variation. Earth-GRAM is a C++ software package; Currently distributed as Earth-GRAM 2016. Atmospheric variables included: pressure, density, temperature, horizontal and vertical winds, speed of sound, and atmospheric constituents. Used by engineering community because of ability to create dispersions inatmosphere at a rapid runtime; Often embedded in trajectory simulation software. Not a forecast model. Does not readily capture localized atmospheric effects.

White, Patrick↗
NASA NTRS2017

Earth Global Reference Atmospheric Model (GRAM) Overview and Updates: DOLWG Meeting

What is Earth-GRAM (Global Reference Atmospheric Model): Provides monthly mean and standard deviation for any point in atmosphere - Monthly, Geographic, and Altitude Variation; Earth-GRAM is a C++ software package - Currently distributed as Earth-GRAM 2016; Atmospheric variables included: pressure, density, temperature, horizontal and vertical winds, speed of sound, and atmospheric constituents; Used by engineering community because of ability to create dispersions in atmosphere at a rapid runtime - Often embedded in trajectory simulation software; Not a forecast model; Does not readily capture localized atmospheric effects.

White, Patrick↗
NASA NTRS2011

Software Defined GPS Receiver for International Space Station

JPL is providing a software defined radio (SDR) that will fly on the International Space Station (ISS) as part of the CoNNeCT project under NASA's SCaN program. The SDR consists of several modules including a Baseband Processor Module (BPM) and a GPS Module (GPSM). The BPM executes applications (waveforms) consisting of software components for the embedded SPARC processor and logic for two Virtex II Field Programmable Gate Arrays (FPGAs) that operate on data received from the GPSM. GPS waveforms on the SDR are enabled by an L-Band antenna, low noise amplifier (LNA), and the GPSM that performs quadrature downconversion at L1, L2, and L5. The GPS waveform for the JPL SDR will acquire and track L1 C/A, L2C, and L5 GPS signals from a CoNNeCT platform on ISS, providing the best GPS-based positioning of ISS achieved to date, the first use of multiple frequency GPS on ISS, and potentially the first L5 signal tracking from space. The system will also enable various radiometric investigations on ISS such as local multipath or ISS dynamic behavior characterization. In following the software-defined model, this work will create a highly portable GPS software and firmware package that can be adapted to another platform with the necessary processor and FPGA capability. This paper also describes ISS applications for the JPL CoNNeCT SDR GPS waveform, possibilities for future global navigation satellite system (GNSS) tracking development, and the applicability of the waveform components to other space navigation applications.

software defined radio (SDR)↗
NASA NTRS2011

MicroShell Minimalist Shell for Xilinx Microprocessors

MicroShell is a lightweight shell environment for engineers and software developers working with embedded microprocessors in Xilinx FPGAs. (MicroShell has also been successfully ported to run on ARM Cortex-M1 microprocessors in Actel ProASIC3 FPGAs, but without project-integration support.) Micro Shell decreases the time spent performing initial tests of field-programmable gate array (FPGA) designs, simplifies running customizable one-time-only experiments, and provides a familiar-feeling command-line interface. The program comes with a collection of useful functions and enables the designer to add an unlimited number of custom commands, which are callable from the command-line. The commands are parameterizable (using the C-based command-line parameter idiom), so the designer can use one function to exercise hardware with different values. Also, since many hardware peripherals instantiated in FPGAs have reasonably simple register-mapped I/O interfaces, the engineer can edit and view hardware parameter settings at any time without stopping the processor. MicroShell comes with a set of support scripts that interface seamlessly with Xilinx's EDK tool. Adding an instance of MicroShell to a project is as simple as marking a check box in a library configuration dialog box and specifying a software project directory. The support scripts then examine the hardware design, build design-specific functions, conditionally include processor-specific functions, and complete the compilation process. For code-size constrained designs, most of the stock functionality can be excluded from the compiled library. When all of the configurable options are removed from the binary, MicroShell has an unoptimized memory footprint of about 4.8 kB and a size-optimized footprint of about 2.3 kB. Since MicroShell allows unfettered access to all processor-accessible memory locations, it is possible to perform live patching on a running system. This can be useful, for instance, if a bug is discovered in a routine but the system cannot be rebooted: Shell allows a skilled operator to directly edit the binary executable in memory. With some forethought, MicroShell code can be located in a different memory location from custom code, permitting the custom functionality to be overwritten at any time without stopping the controlling shell.

Werne, Thomas A.↗
NASA NTRS2008

REVEAL: Software Documentation and Platform Migration

The Research Environment for Vehicle Embedded Analysis on Linux (REVEAL) is reconfigurable data acquisition software designed for network-distributed test and measurement applications. In development since 2001, it has been successfully demonstrated in support of a number of actual missions within NASA s Suborbital Science Program. Improvements to software configuration control were needed to properly support both an ongoing transition to operational status and continued evolution of REVEAL capabilities. For this reason the project described in this report targets REVEAL software source documentation and deployment of the software on a small set of hardware platforms different from what is currently used in the baseline system implementation. This report specifically describes the actions taken over a ten week period by two undergraduate student interns and serves as a final report for that internship. The topics discussed include: the documentation of REVEAL source code; the migration of REVEAL to other platforms; and an end-to-end field test that successfully validates the efforts.

Wilson, Michael A.↗
NASA NTRS2011

REVEAL: Software Documentation and Platform Migration

The Research Environment for Vehicle Embedded Analysis on Linux (REVEAL) is reconfigurable data acquisition software designed for network-distributed test and measurement applications. In development since 2001, it has been successfully demonstrated in support of a number of actual missions within NASA's Suborbital Science Program. Improvements to software configuration control were needed to properly support both an ongoing transition to operational status and continued evolution of REVEAL capabilities. For this reason the project described in this report targets REVEAL software source documentation and deployment of the software on a small set of hardware platforms different from what is currently used in the baseline system implementation. This presentation specifically describes the actions taken over a ten week period by two undergraduate student interns and serves as an overview of the content of the final report for that internship.

Wilson, Michael A.↗
DOE OSTI2026

DISARM: Target Electronic Device Informed Mitigation of Software Runtime Side-Channel Vulnerabilities

Program runtime/timing attacks exploit variations in a program’s execution times to extract sensitive information from the program (e.g. encryption keys, sensitive variable data, intellectual property). State-of-the-art solutions to runtime side-channel attacks attempt to balance the execution time of the sensitive code for different control flow paths to eliminate the timing leakage. However, during the mitigation process, most techniques do not consider the underlying hardware/device on which the target program is supposed to run on. This can lead to over-fixing (unnecessary extra operations), under-fixing (not solving the imbalance properly), and even failures. Here, we propose DISARM, a joint hardware-software methodology (unlike any existing solution) for mitigating runtime side-channel vulnerabilities that utilizes timing values from real embedded devices to generate targeted software fixes. We implement DISARM to support C/C++/Java source codes and validate it across 22 standard benchmarks. DISARM outperforms state-of-the-art solutions such as PENDULUM and DifFuzzaR in terms of execution time overhead, code size overhead, and correctness on five different embedded/edge devices.

Timing/runtime side-channel↗
DOE OSTI2026

Hardware Aware Mitigation of Timing Side-Channel Vulnerabilities in Critical Infrastructure Software

Program runtime/timing attacks exploit variations in a program’s execution times to extract sensitive information from the program (e.g. encryption keys, sensitive variable data, intellectual property). State-of-the-art solutions to runtime sidechannel attacks attempt to balance the execution time of the sensitive code for different control flow paths to eliminate the timing leakage. However, during the mitigation process, most techniques do not consider the underlying hardware/device on which the target program is supposed to run on. This can lead to over-fixing (unnecessary extra operations), under-fixing (not solving the imbalance properly), and even failures. We propose DISARM, a joint hardware-software methodology (unlike any existing solution) for mitigating runtime side-channel vulnerabilities that utilizes timing values from real embedded devices to generate targeted software fixes. We implement DISARM to support C/C++/Java source codes and validate it across 22 standard benchmarks. DISARM outperforms state-of-the-art solutions such as PENDULUM and DifFuzzAR in terms of execution time overhead (up to −46%), code size overhead (up to −10%), and correctness (no failures) on five different embedded/edge devices.

Suha, Tasneem [University of Maine]↗
DOE OSTI2020

Innovations in Building Energy Modeling: Research and Development Opportunities for Emerging Technologies

Building energy modeling (BEM) is a multipurpose tool for building energy efficiency (EE). The U.S. Department of Energy Building Technologies Office (BTO) seeks to expand the use and effectiveness of BEM in the design and operation of commercial and residential buildings with the goal of achieving lasting reductions in total and peak energy use. This report identifies gaps and outlines recommended initiatives to achieve this goal, based on a combination of technical analysis and stakeholder input. In addition to BTO, this report can benefit BEM professionals (architects, mechanical engineers, energy consultants, building auditors, equipment manufacturers, and BEM software vendors) and BEM clients (building owners and operators, EE program administrators, EE service providers, policymakers, and policy and code jurisdictions such as states and cities). This report was developed in two phases. In the first, BTO worked with a team from Navigant Consulting (now Guidehouse) to characterize objectives, opportunities, and current activities; identify gaps and barriers; and define initiatives. To collect input, Navigant conducted telephone interviews and workshops with industry experts. The initial phase produced a draft report, which was released for public review in 2016 and yielded over 400 comments. Based on these comments, BTO compiled a second draft report that addressed many of those comments while acknowledging changes that had occurred both at BTO and in the industry. Unlike the first draft report, the second focused much more heavily on BTO’s own role, portfolio, and activities. BTO is a direct player in the BEM field - it funds the development of several significant software packages that are embedded in commercial products - and transparency about its goals and future plans is requisite. BTO recognizes that a great number of other public and private organizations contribute to the BEM enterprise. With the second draft report, BTO did not attempt to produce a blueprint for the industry as a whole, but rather a working document BTO can use to iteratively solicit stakeholder input and synthesize it into a program. BTO released the second draft report for public review in 2019. The second round of review generated 83 pages of feedback and comments - almost exactly the length of the draft report itself - a significant portion of which was collected and synthesized by IBPSA-USA Advocacy Committee. This final report incorporates this feedback. This report does not address the use of BEM in support of building-based grid services, a recent BTO initiative called Grid-interactive Efficient Buildings (GEB). In 2019, BTO published a report that specifically addresses the role of BEM - and other “integration” technologies - in GEB.

32 ENERGY CONSERVATION, CONSUMPTION, AND UTILIZATI↗
NASA NTRS1981

Cleanroom software development

The 'cleanroom' software development process is a technical and organizational approach to developing software with certifiable reliability. Key ideas behind the process are well structured software specifications, randomized testing methods and the introduction of statistical controls; but the main point is to deny entry for defects during the development of software. This latter point suggests the use of the term 'cleanroom' in analogy to the defect prevention controls used in the manufacturing of high technology hardware. In the 'cleanroom', the entire software development process is embedded within a formal statistical design, in contrast to executing selected tests and appealing to the randomness of operational settings for drawing statistical inferences. Instead, random testing is introduced as a part of the statistical design itself so that when development and testing are completed, statistical inferences are made about the operation of the system.

Dyer, M.↗