Engineering Papers⌕ Search

SEARCH · Engineering Papers

Results for “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 685 records · Page 38
All sourcesNASA NTRSDOE OSTI
NASA NTRS2015

Planning the Unplanned Experiment: Towards Assessing the Efficacy of Standards for Safety-Critical Software

Safe use of software in safety-critical applications requires well-founded means of determining whether software is fit for such use. While software in industries such as aviation has a good safety record, little is known about whether standards for software in safety-critical applications 'work' (or even what that means). It is often (implicitly) argued that software is fit for safety-critical use because it conforms to an appropriate standard. Without knowing whether a standard works, such reliance is an experiment; without carefully collecting assessment data, that experiment is unplanned. To help plan the experiment, we organized a workshop to develop practical ideas for assessing software safety standards. In this paper, we relate and elaborate on the workshop discussion, which revealed subtle but important study design considerations and practical barriers to collecting appropriate historical data and recruiting appropriate experimental subjects. We discuss assessing standards as written and as applied, several candidate definitions for what it means for a standard to 'work,' and key assessment strategies and study techniques and the pros and cons of each. Finally, we conclude with thoughts about the kinds of research that will be required and how academia, industry, and regulators might collaborate to overcome the noted barriers.

Graydon, Patrick J.↗
NASA NTRS2016

NASA Operational Simulator for Small Satellites: Tools for Software Based Validation and Verification of Small Satellites

The NASA Operational Simulator for Small Satellites (NOS3) is a suite of tools to aid in areas such as software development, integration test (IT), mission operations training, verification and validation (VV), and software systems check-out. NOS3 provides a software development environment, a multi-target build system, an operator interface-ground station, dynamics and environment simulations, and software-based hardware models. NOS3 enables the development of flight software (FSW) early in the project life cycle, when access to hardware is typically not available. For small satellites there are extensive lead times on many of the commercial-off-the-shelf (COTS) components as well as limited funding for engineering test units (ETU). Considering the difficulty of providing a hardware test-bed to each developer tester, hardware models are modeled based upon characteristic data or manufacturers data sheets for each individual component. The fidelity of each hardware models is such that FSW executes unaware that physical hardware is not present. This allows binaries to be compiled for both the simulation environment, and the flight computer, without changing the FSW source code. For hardware models that provide data dependent on the environment, such as a GPS receiver or magnetometer, an open-source tool from NASA GSFC (42 Spacecraft Simulation) is used to provide the necessary data. The underlying infrastructure used to transfer messages between FSW and the hardware models can also be used to monitor, intercept, and inject messages, which has proven to be beneficial for VV of larger missions such as James Webb Space Telescope (JWST). As hardware is procured, drivers can be added to the environment to enable hardware-in-the-loop (HWIL) testing. When strict time synchronization is not vital, any number of combinations of hardware components and software-based models can be tested. The open-source operator interface used in NOS3 is COSMOS from Ball Aerospace. For testing, plug-ins are implemented in COSMOS to control the NOS3 simulations, while the command and telemetry tools available in COSMOS are used to communicate with FSW. NOS3 is actively being used for FSW development and component testing of the Simulation-to-Flight 1 (STF-1) CubeSat. As NOS3 matures, hardware models have been added for common CubeSat components such as Novatel GPS receivers, ClydeSpace electrical power systems and batteries, ISISpace antenna systems, etc. In the future, NASA IVV plans to distribute NOS3 to other CubeSat developers and release the suite to the open-source community.

Verification↗
NASA NTRS2019

Improving Security of Ground System Software

An estimated 84% of all security breaches are application-related, not firewall violations. To what extent is your organization focused on addressing security issues in its software? Software plays a critical role in mission success, and software similarly plays a role in mission security. However, software can introduce vulnerabilities to the system, such as use of a COTS product that has a backdoor, or a hole in the security of the system deliberately left in place by designers or maintainers. The motivations for such holes are not always sinister, but can provide a means for malicious intrusion into the mission. Students will learn an approach to securing ground software within the context of federal information systems. Federal requirements, coding standards, tool usage will be discussed as part of the solution to securing software.

Bailey, Brandon↗
NASA NTRS2019

Agile Approach to Assuring the Safety-Critical Embedded Software for NASA's Orion Spacecraft

Human-rated missions like those in NASA's Orion Program continue to grow in complexity. The role of software in achieving ambitious mission objectives has expanded dramatically in the last few decades. Assuring the safety and performance of the embedded flight software is quickly growing beyond the reach of traditional methods and resource levels. The methods used to build these software-dominant systems evolve in an on-going attempt to keep pace with the scope of our ambitions. Agile software development is now commonplace. The long timelines and large batches of work associated with traditional methods are being replaced by rapid delivery of small increments _ as system capabilities are realized in waves. Assurance of these critical software capabilities must therefore conquer an ever-expanding frontier of challenges, and do so with an approach matched to the evolving development methods. This paper recounts the journey of the Orion Independent Verification and Validation (IV&V) team as we addressed this dynamic environment. Widening our aperture to encompass a dramatically larger mission scope, while adjusting our cadence to synchronize with the rapid pace of agile software development, a new approach to IV&V is emerging. This approach is characterized by a sharper focus on mission capabilities, matched with a method to dynamically _follow the risk' as the IV&V team delivers more compelling assurance data in waves. Traditional methods prevalent in IV&V tend to scope the work using artifacts of the development process as they evolve from preliminary to final versions, and the pace of delivery was synchronized with the development timelines prevalent in the waterfall lifecycle. That more static approach is out of phase with the demands of the new environment. Scoping work according to the critical capabilities of the system (rather than artifacts of development) and synchronizing with the rapid pace of agile development, we are moving toward more effective parity with the demands of the environment. We explain the concrete steps we took, the principles that motivated our choices, and the results we have achieved to date.

Capability based assurance↗
NASA NTRS2019

Agile Approach to Assuring the Safety-Critical Embedded Software for NASA's Orion Spacecraft

Human-rated missions like NASA's Exploration Mission - 1 (EM-1) and the Orion Multi-Purpose Crew Vehicle are becoming exceedingly complex in terms of software's contribution to achieving mission objectives. The increasing complexity and inherent safety critical nature of the embedded flight software imposes a unique resource challenge to assurance providers responsible for affirming that the mission is going to fly safely. Another challenge NASA and other Government agencies are facing is that more and more software is being developed using an agile development methodology, which is divergent from the typical waterfall, iterative, and incremental development methodologies assurance providers generally observe in the development of safety-critical embedded software. Orion Independent Verification and Validation (IV&V) has addressed these challenges by providing focused assurance results of critical mission capabilities prioritized by a dynamic assessment of risk level. Prior to this approach, Orion IV&V evaluated areas of risk in much broader, and more static, terms. Due to the agile software development life cycle that Orion follows, IV&V findings were often reported months out of phase with the developer thereby imposing increased rework costs. As a result of evolving the approach to adding assurance on Orion, IV&V is able to incrementally deliver high-priority assurance conclusions and more impactful issues more in phase with the developer activities, thereby increasing the value of the findings to the project. The agile IV&V approach employed by the Orion IV&V team strives to achieve a cadence of delivery that matches the pace of development. This agile approach provides increased flexibility for the assurance provider to become more efficient in reporting assurance conclusions and issues. This paper and presentation will discuss the principles which drive the design of our approach, results to date, and stimulate thinking for groups looking to add assurance to software being developed using an agile methodology.

Justin Smith↗
NASA NTRS2019

Benefits and Challenges of Model-based Software Engineering: Lessons Learned based on Qualitative and Quantitative Findings

Even though Model-based Software Engineering (MBSwE) techniques and Autogenerated Code (AGC) have been increasingly used to produce complex software systems, there is only anecdotal knowledge about the state-of-thepractice. Furthermore, there is a lack of empirical studies that explore the potential quality improvements due to the use of these techniques. This paper presents in-depth qualitative findings about development and Software Assurance (SWA) practices and detailed quantitative analysis of software bug reports of a NASA mission that used MBSwE and AGC. The mission’s flight software is a combination of handwritten code and AGC developed by two different approaches: one based on state chart models (AGC-M) and another on specification dictionaries (AGC-D). The empirical analysis of fault proneness is based on 380 closed bug reports created by software developers. Our main findings include: (1) MBSwE and AGC provide some benefits, but also impose challenges. (2) SWA done only at a model level is not sufficient. AGC code should also be tested and the models and AGC should always be kept in-sync. AGC must not be changed manually. (3) Fixes made to address an individual bug report were spread both across multiple modules and across multiple files. On average, for each bug report 1.4 modules, that is, 3.4 files were fixed. (4) Most bug reports led to changes in more than one type of file. The majority of changes to auto-generated source code files were made in conjunction to changes in either file with state chart models or XML files derived from dictionaries. (5) For newly developed files, AGC-M and handwritten code were of similar quality, while AGC-D files were the least fault prone.

Goseva-Popstojanova, Katerina↗
NASA NTRS2018

Software System for the Mars 2020 Mission Sampling and Caching Testbeds

The development of the Sampling and Caching Subsystem (SCS) of the Mars 2020 Rover Mission is highly dependent on testing of prototype hardware and software operating in explicit conditions as part of integrated testbeds. To achieve relevant integration of hardware and software while maintaining rapid algorithm development capabilities and high testing throughput, the Controls and Autonomy for Sample Acquisition and Handling (CASAH) software system was developed. CASAH is an implementation of the Intelligent Robotics System Architecture (IRSA),which mimics JPL Flight Software (FSW) in that it is divided into hierarchical modules that run separate processes that communicate via message passing, each module is assigned an owner that is a single developer, and the operator initiates requests via a text-based interface that interprets sequences of commands.IRSA enables a modular breakdown of CASAH that follows that of 2020 Flight Software,so developers can take an algorithm from a module in CASAH and re-code it into the same module in FSW. As deployment of CASAH has grown to ten testbeds - each with different hardware and objectives - bottom-up design decisions have been intentionally made to keep the system lightweight and maintainable by a very small team. To date, CASAH has been used to run 1393 different tests. This work describes CASAH, the testbeds and functionality it supports, the tools used to manage the development and sharing of code, and the features of the software. Lessons learned over the past three years of development and deployment are provided.

Vieira, Peter↗
NASA NTRSDate not supplied

Certification Considerations for Adaptive Stress Testing of Airborne Software

eduAdaptive Stress Testing (AST) has shown promise in identifying errant corner cases in complex software used in aerospace applications including Flight Management Systems (FMS). The strength of AST is performing test-based verification of complex aerospace software intensive systems at scale in simulated operational environments.Simulating and capturing the realistic operational complexities in integrated verification environments may exposeflaws in the softwareprior to field deployment, whereas the software may perform just fine to traditional requirements-basedunit and component level testing.AST can be used to test the whole system.Individual components may behave safely, but together can result in complex interactions and emergent failures, so it is important to test at the integrated system level.Motivated by the observed benefitsat the prototype proof of concept scale, this paper considers how AST may be integrated into a production workflow and used to generate objective evidence in a processthat delivers certified aerospace software.The research includes evaluation of alignment with both DO-178C and Overarching Properties(OP). The paper addresses questions such as “where should AST fit in the Plan for Software Aspects of Certification (PSAC) and Software Verification Plan (SVP), what aspects of AST do not fit, and what objectives does it satisfy?” The paper concludes that AST is in fact useful at locating errors in complex airborne application software and in doing so provides benefits to suppliers and end users. Furthermore, AST appears appropriate to add value in both DO-178Cbased and Overarching Properties based certification approaches.

certification↗
NASA NTRSDate not supplied

A System to Provide Deterministic Flight Software Operation and Maximize Multicore Processing Performance: The Safe and Precise Landing – Integrated Capabilities Evolution (SPLICE) Datapath

A method and design are described for a system that processes multiple data streams, utilizing a multicore asymmetric processing architecture, that eliminates data interrupts to the application processors. The design supports a deterministic environment for flight software in NASA’s Safe and Precise Landing – Integrated Capabilities Evolution (SPLICE) project. The SPLICE project develops sensor, algorithm, and compute technologies for Precision Landing and Hazard Avoidance (PL&HA) capabilities. The compute technology for SPLICE is the Descent and Landing Computer (DLC). The DLC hosts several SPLICE algorithms with high computational resource requirements that must be executed in a real-time and deterministic manner. The software runs on a custom Single Board Computer (SBC), with a Xilinx Ultrascale+ Multiprocessor System-on-a-Chip (MPSoC). Input data for the flight software is from a variety of sensors, unique with respect to data rate and packet size. A data path between the SPLICE sensors and algorithms is designed to efficiently deliver this data to the flight software using the MPSoC asymmetric processing cores and Field Programmable Gate Array (FPGA) fabric. This is implemented in a manner that isolates the application processors running the flight software from interrupts associated with the input data. By leveraging real-time processors on the MPSoC, and a structure with the appropriate interfaces in the shared memory on the SBC, the flight software can use the full set of application processors. The available utilization for each processor in this set is also maximized for the SPLICE applications, providing a sufficiently deterministic execution environment without the cost and overhead of a real-time operating system.

heterogeneous processing system↗
NASA NTRSDate not supplied

Flight Software for the LOFTID Re-Entry Vehicle

NASA’s Low-Earth Orbit Flight Test of an Inflatable Decelerator, or LOFTID, demonstrated re-entry from low-Earth orbit of a 6-meter aeroshell designed to be used as a heat shield that is larger than the rocket shroud, enabling the return of much greater mass. The LOFTID Flight Software was developed in-house and consists of three components: the Power Distribution software, the Data Recorder software, and the Camera Controller software, along with the Ground Software used for testing, operations, data integrity, and data processing. This presentation will discuss issues found in developing the Power Distribution software in cFS on a non-Linux POSIX platform, designing an efficient architecture for recording of high bandwidth data, controlling over a dozen cameras in-flight, and creating the ground support tools to verify data integrity and support the post-processing of flight data.

Paul Brewster↗
NASA NTRS2023

A System to Provide Deterministic Flight Software Operation and Maximize Multicore Processing Performance: The Safe and Precise Landing – Integrated Capabilities Evolution (SPLICE) Datapath

A method and design are described for a system that processes multiple data streams, utilizing a multicore asymmetric processing architecture, that eliminates data interrupts to the application processors. The design supports a deterministic environment for flight software in NASA’s Safe and Precise Landing – Integrated Capabilities Evolution (SPLICE) project. The SPLICE project develops sensor, algorithm, and compute technologies for Precision Landing and Hazard Avoidance (PL&HA) capabilities. The compute technology for SPLICE is the Descent and Landing Computer (DLC). The DLC hosts several SPLICE algorithms with high computational resource requirements that must be executed in a real-time and deterministic manner. The software runs on a custom Single Board Computer (SBC), with a Xilinx Ultrascale+ Multiprocessor System-on-a-Chip (MPSoC). Input data for the flight software is from a variety of sensors, unique with respect to data rate and packet size. A data path between the SPLICE sensors and algorithms is designed to efficiently deliver this data to the flight software using the MPSoC asymmetric processing cores and Field Programmable Gate Array (FPGA) fabric. This is implemented in a manner that isolates the application processors running the flight software from interrupts associated with the input data. By leveraging real-time processors on the MPSoC, and a structure with the appropriate interfaces in the shared memory on the SBC, the flight software can use the full set of application processors. The available utilization for each processor in this set is also maximized for the SPLICE applications, providing a sufficiently deterministic execution environment without the cost and overhead of a real-time operating system.

David K. Rutishauser↗
NASA NTRSDate not supplied

Autonomous Navigation, Guidance, and Control Software in a Low SWaP Box

Onboard autonomy is a necessity for responsive space operations. Autonomous navigation, guidance, and control (NGC) enables space missions to reduce their dependence on high demand ground assets and costly ground personnel. It also allows for in-situ decision making and higher return on mission data. A flight software and hardware system providing this capability, called “autoNGC,” is currently being developed at NASA Goddard Space Flight Center for infusion into multiple future missions. The autoNGC flight software is built on the plug-and-play architecture of the core Flight System (cFS) consisting of the standard cFS apps and newly developed autoNGC interface apps and libraries. The various apps cooperate through communication over the message-based software bus. With the plug-and-play architecture of autoNGC, cFS apps can easily be added and replaced to meet the needs of different missions, even after launch. The first flight software release of autoNGC is targeted for Summer 2024 to provide autonomous navigation at the Moon and beyond. It can perform sensor fusion of multiple measurement types including pseudo-range from a Global Navigation Satellite System (GNSS) receiver (including weak signal), 1-way and 2-way range and Doppler from ground stations (i.e., direct to Earth (DTE)), bearing and range from optical camera images, and accelerometer data. Accurate onboard navigation and timing is obtained through the Goddard Enhanced Onboard Navigation System (GEONS) software library which fuses different measurement types through an extended Kalman filter (EKF) framework. Optical measurements that are ingested in GEONS are first extracted from optical images by the cFS Goddard Image Analysis and Navigation Tool (cGIANT) app. If the imaged body is far enough away that it appears as a pixel or cluster of pixels, then bearing angles to the body centroid can be provided. If the body is close enough and the shape is known coarsely, then bearing angles and range to the body centroid can be derived from the limb. Bearing angles to individual surface features can also be extracted (i.e., terrain relative navigation (TRN)). Onboard guidance and control capabilities are being developed for a future release to perform autonomous station-keeping and trajectory correction maneuvers in multiple orbital regimes. Capabilities to enable distributed systems missions and constellations, such as crosslink measurements, and onboard time management are being developed as well. The first hardware implementation of autoNGC is a minimal size, weight, and power (SWaP) design allowing for inclusion into CubeSats and SmallSat-size buses. Advancements in miniaturized space processors, such as the SpaceCube 3.0 Mini and the SpaceCube Mini-Z are utilized for low SWaP while maintaining a high level of performance. The current enclosure design is 12 cm x 17 cm x 13.5 cm. The box mass is expected to be less than 2 kg, and the nominal power is 21 W. In order to accommodate a wide range of missions, the hardware interfaces are designed for flexibility with a variety of sensor inputs. Through comprehensive testing in the software-in-the-loop, processor-in-the-loop, and hardware-in-the-loop test beds that are concurrently being developed, autoNGC is expected to achieve TRL 6 by late 2024.

Sun Hur-Diaz↗
NASA NTRS2024

Freddie Software Security Patching

Software applications become more complicated over time as they depend on many third-party, open-source libraries. The Freddie Platform Services team actively improves software security by addressing software bugs and vulnerabilities that negatively impact software applications, especially those providing real-time operations and services for the federal partners and industries. In order to detect bugs and patch vulnerabilities in software development and maintenance cycles, an automated and systematic approach is needed. This document describes what bugs and vulnerabilities are, and how they can be detected by using static code analyzers and software composition analysis tools. Once vulnerabilities are detected, the patching approaches, such as upgrading direct and transitive dependencies and loading custom classes first, are presented together with their strengths and weaknesses. In addition, patching walkthrough, example code, lessons learned throughout the vulnerability patching process and the recommended practices are discussed.

Chok Fung Lai↗
DOE OSTI2013

The Many Faces of a Software Engineer in a Research Community

The ability to gather, analyze and make decisions based on real world data is changing nearly every field of human endeavor. These changes are particularly challenging for software engineers working in a scientific community, designing and developing large, complex systems. To avoid the creation of a communications gap (almost a language barrier), the software engineers should possess an ‘adaptive’ skill. In the science and engineering research community, the software engineers must be responsible for more than creating mechanisms for storing and analyzing data. They must also develop a fundamental scientific and engineering understanding of the data. This paper looks at the many faces that a software engineer should have: developer, domain expert, business analyst, security expert, project manager, tester, user experience professional, etc. Observations made during work on a power-systems scientific software development are analyzed and extended to describe more generic software development projects.

agile methodologies↗
DOE OSTI2016

Idea Paper: The Lifecycle of Software for Scientific Simulations

The software lifecycle is a well researched topic that has produced many models to meet the needs of different types of software projects. However, one class of projects, software development for scientific computing, has received relatively little attention from lifecycle researchers. In particular, software for end-to-end computations for obtaining scientific results has received few lifecycle proposals and no formalization of a development model. An examination of development approaches employed by the teams implementing large multicomponent codes reveals a great deal of similarity in their strategies. This idea paper formalizes these related approaches into a lifecycle model for end-to-end scientific application software, featuring loose coupling between submodels for development of infrastructure and scientific capability. We also invite input from stakeholders to converge on a model that captures the complexity of this development processes and provides needed lifecycle guidance to the scientific software community.

Dubey, Anshu↗
DOE OSTI2020

Software classification using phylogenetic techniques

Software, such as malware, may be classified using phylogenetic techniques. An evolutionary history of a representative set of software programs may be reconstructed to generate a reference phylogeny. Dynamic traces of the representative software programs may be obtained. The dynamic traces may include time-ordered sequences of execution commands extracted from running software binaries. Metrics may be developed using the dynamic traces. One or more unknown software programs may then be classified against the reference phylogeny using the metrics developed using the dynamic traces of the representative set of software programs.

97 MATHEMATICS AND COMPUTING↗
DOE OSTI2020

Teaching Software Sustainability for High Performance Computing at ATPESC

The Argonne Training Program in Extreme Scale Computing (ATPESC) was started by Argonne National Laboratory with the objective of expanding the ranks of better-prepared users of high-performance computing (HPC) machines. One of the unique aspects of the program was inclusion of a track on software engineering and community codes. The inclusion was motivated by the observation that the projects with good software processes were better able to meet their scientific goals. Over the years, with greater awareness of software sustainability issues in the community, the track has evolved into a software productivity and sustainability track. In this paper we present our experience in choosing and disseminating the content related to the topic of software engineering in high performance computing science from the beginning of the program until now. We discuss the motivations and the reception of the tracks. We also document the evolution of the track over the years based on student feedback and also the growth of awareness about software productivity in high performance computing.

Dubey, Anshu↗
DOE OSTI2020

Automated Data Acquisition Software for National Instruments Hardware with Timed Acquisition, Real-Time Display and Spectrogram, and Data Redundancy. Current version is Version 7 of DataAcq.exe.RElease1.2.4.26.

This software automates the collection of waveform data on a timed schedule so that an operator does not need to be at the computer to initiate the collection of data sets.It provides real time display of up to 16 channels of data as a time display, frequency display, or frequency vs time (spectrogram) display. The software provides the ability to collect data sets of a user selected time length at a selected interval. This operation can be set to occur during a selected time interval during the day. This software provides the capability to write two copies of the data files simultaneously so that the data is backed up as collected. This software automates the collection of waveform data on a timed schedule so that an operator does not need to be at the computer to initiate the collection of data sets. It provides real time display of up to 16 channels of data as a time display, frequency display, or frequency vs time (spectrogram) display. The software provides the ability to collect data sets of a user selected time length at a selected interval. This operation can be set to occur during a selected time interval during the day. This software provides the capability to write two copies of the data files simultaneously so that the data is backed up as collected.

Wysor, Robert W↗