SEARCH · Search NASA
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.
In the complex environment of JPL's flight missions with increasing dependency on advanced software designs, traditional software validation methods of simulation and testing are being stretched to adequately cover the needs of software development.
Modeling guidelines constitute one of the fundamental cornerstones for Model Based Development. Their relevance is essential when dealing with code generation in the safety-critical domain. This article presents the experience of a railway signaling systems manufacturer on this issue. Introduction of Model-Based Development (MBD) and code generation in the industrial safety-critical sector created a crucial paradigm shift in the development process of dependable systems. While traditional software development focuses on the code, with MBD practices the focus shifts to model abstractions. The change has fundamental implications for safety-critical systems, which still need to guarantee a high degree of confidence also at code level. Usage of the Simulink/Stateflow platform for modeling, which is a de facto standard in control software development, does not ensure by itself production of high-quality dependable code. This issue has been addressed by companies through the definition of modeling rules imposing restrictions on the usage of design tools components, in order to enable production of qualified code. The MAAB Control Algorithm Modeling Guidelines (MathWorks Automotive Advisory Board)[3] is a well established set of publicly available rules for modeling with Simulink/Stateflow. This set of recommendations has been developed by a group of OEMs and suppliers of the automotive sector with the objective of enforcing and easing the usage of the MathWorks tools within the automotive industry. The guidelines have been published in 2001 and afterwords revisited in 2007 in order to integrate some additional rules developed by the Japanese division of MAAB [5]. The scope of the current edition of the guidelines ranges from model maintainability and readability to code generation issues. The rules are conceived as a reference baseline and therefore they need to be tailored to comply with the characteristics of each industrial context. Customization of these recommendations has been performed for the automotive control systems domain in order to enforce code generation [7]. The MAAB guidelines have been found profitable also in the aerospace/avionics sector [1] and they have been adopted by the MathWorks Aerospace Leadership Council (MALC). General Electric Transportation Systems (GETS) is a well known railway signaling systems manufacturer leading in Automatic Train Protection (ATP) systems technology. Inside an effort of adopting formal methods within its own development process, GETS decided to introduce system modeling by means of the MathWorks tools [2], and in 2008 chose to move to code generation. This article reports the experience performed by GETS in developing its own modeling standard through customizing the MAAB rules for the railway signaling domain and shows the result of this experience with a successful product development story.
External development of software has oftc n led to unsatisfactory results and great frustration for the assurE 7ce community. Contracts frequently omit critical assuranc 4 processes or the right to oversee software development activitie: At a time when NASA depends more and more on software to in plement critical system functions, combination of three factors ex; cerbate this problem: I ) the ever-increasing trend to acquire rather than develop software in-house, 2) the trend toward performance based contracts, and 3) acquisition vehicles that only state softwar 2 requirements while leaving development standards and assur! ince methodologies up to the contractor. We propose to identify specific methods at d tools that NASA projects can use to mitigate the adverse el ects of the three problems. TWO broad classes of methoddt ~ols will be explored. The first will be those that provide NASA p ojects with insight and oversight into contractors' activities. The st cond will be those that help projects objectively assess, and thus i nprwe, their software acquisition capability. Of particular interest is the Software Engineering Institute's (SEI) Software Acqt isition Capability Maturity Model (SA-CMMO).
A candidate onboard space navigation filter demonstrated excellent performance (less than 8 meter level RMS semi-major axis accuracy) in performing orbit determination of a low-Earth orbit Explorer satellite using single-frequency real GPS data. This performance is significantly better than predicted by other simulation studies using dual-frequency GPS data. The study results revealed the significance of two new modeling approaches evaluated in the work. One approach introduces a single-frequency ionospheric correction through pseudo-range and phase range averaging implementation. The other approach demonstrates a precise axis-dependent characterization of dynamic sample space uncertainty to compute a more accurate Kalman filter gain. Additionally, this navigation filter demonstrates a flexibility to accommodate both perturbational dynamic and observational biases required for multi-flight phase and inhomogeneous application environments. This paper reviews the potential application of these methods and the filter structure to terrestrial vehicle and positioning applications. Both the single-frequency ionospheric correction method and the axis-dependent state noise modeling approach offer valuable contributions in cost and accuracy improvements for terrestrial GPS receivers. With a modular design approach to either 'plug-in' or 'unplug' various force models, this multi-flight phase navigation filter design structure also provides a versatile GPS navigation software engine for both atmospheric and exo-atmospheric navigation or positioning use, thereby streamlining the flight phase or application-dependent software requirements. Thus, a standardized GPS navigation software engine that can reduce the development and maintenance cost of commercial GPS receivers is now possible.
No abstract available
Abstract not provided.
Abstract not provided.
This paper demonstrates a methodology to model and evaluate the fault tolerance characteristics of operational software. The methodology is illustrated through case studies on three different operating systems: the Tandem GUARDIAN fault-tolerant system, the VAX/VMS distributed system, and the IBM/MVS system. Measurements are made on these systems for substantial periods to collect software error and recovery data. In addition to investigating basic dependability characteristics such as major software problems and error distributions, we develop two levels of models to describe error and recovery processes inside an operating system and on multiple instances of an operating system running in a distributed environment. Based on the models, reward analysis is conducted to evaluate the loss of service due to software errors and the effect of the fault-tolerance techniques implemented in the systems. Software error correlation in multicomputer systems is also investigated.
A study was conducted to determine the feasibility of using knowledge-based systems architectures for inflight research of primary flight display information management issues. The feasibility relied on the ability to integrate knowledge-based systems with existing onboard aircraft systems. And, given the hardware and software platforms available, the feasibility also depended on the ability to use interpreted LISP software with the real time operation of the primary flight display. In addition to evaluating these feasibility issues, the study determined whether the software engineering advantages of knowledge-based systems found for this application in the earlier workstation study extended to the inflight research environment. To study these issues, two integrated knowledge-based systems were designed to control the primary flight display according to pre-existing specifications of an ongoing primary flight display information management research effort. These two systems were implemented to assess the feasibility and software engineering issues listed. Flight test results were successful in showing the feasibility of using knowledge-based systems inflight with actual aircraft data.
Spacecraft thermal protection systems require unique approaches for design verification due to the extreme environments seen during space travel and atmospheric re-entry. In this work, unique considerations for design, analysis, and verification of a tiled heatshield design with material nonlinearity, material property temperature-dependency, material property rate-dependency, and geometric stress concentrations are presented. Such designs require a thorough application of the building block approach to derive appropriate material property datasets, and a novel application of analysis models to aid in the structural verification with testing. The custom application of material rate-dependency in finite element analysis software is presented as a means of leveraging the rate-dependent test data for the material property dataset. Because bonded tile heatshields contain so many design considerations and nonlinearities which often preclude the ability to easily achieve the requisite test factors in qualification testing, a novel sub-element test was developed that amplifies the stress singularity beyond flight conditions. The test achieves an over-test over flight stress conditions. The approach for sub-element coupon design can be extended to other bonded joint designs and can be used in aiding a qualification program.
High Energy Physics (HEP) software environments often involve ~ hundreds of external packages and libraries, and similar numbers of experiment-specific, science-critical packages—many under continuous development. Managing coherent releases of the external software stack is challenging enough, but managing the highly-collaborative—and distributed—development of a large body of code against such a stack adds even more complexity and room for error. Spack is a popular Python-based package management tool with a specific focus on the needs of High Performance Computing (HPC) systems and system administrators whose strength is orchestrating the discrete download, build, testing, and installation of pre-packaged or tagged third-party software against similarly stable dependencies. As such it is becoming increasingly popular within HEP as that community makes increasing use of HPC facilities, and as efforts to develop future HPC systems utilize Spack to provide scientific software on those platforms. SpackDev is a system to facilitate the simultaneous development of interconnected sets of packages. Intended to handle packages without restriction to one internal build system, SpackDev is integrated with Spack as a command extension in order to leverage features such as dependency calculations and build system configuration, and is generally applicable outside HEP. We describe SpackDev’s features and development over the last two years, initial experience using SpackDev in the context of the LArSoft liquid argon detector toolkit, and work remaining before it can be considered a fully-functional multi-package build system for HEP experiments utilizing Spack.
Nuclear power plants (NPP) have thousands of digital assets throughout their facility. Typically, NPPs have asset and configuration management programs that capture the make, model, and version of a component. This information, however, usually only includes first- or second-tier components and does not capture the complete enumeration of software components and their dependencies within operational technology (OT) equipment. As seen with recent cyberattacks, this level of detail is insufficient for identifying if and where an exploitable vulnerability exists within a facility. A software bill of materials (SBOM) provides this detailed enumeration. Further, integrating SBOMs with vulnerability data sources and vulnerability attestation reports can provide improved awareness leading to better cyber risk management and incident response. Preferably, SBOMs are provided by the supplier; however, when an NPP already owns a device, it is less likely they will have a supplier provided-SBOM. Fortunately, SBOMs can be generated on installed digital assets. This paper provides an introduction to the U.S. Department of Energy Office of Nuclear Energy paper titled “Towards Software Bill of Materials in the Nuclear Industry,” which describes the SBOM ecosystem and provides a suggested approach to methodically and seamlessly integrate an SBOM program in an NPP.
Package managers provide ease of access to applications by removing the time-consuming and sometimes completely prohibitive barrier of successfully building, installing, and maintaining the software for a system. A package dependency contains dependencies between all packages required to build and run the target software. Package management system developers, package maintainers, and users may consult the dependency graph when a simple listing is insufficient for their analyses. However, users working in a remote command line environment must disrupt their workflow to visualize dependency graphs in graphical programs, possibly needing to move files between devices or incur forwarding lag. Such is the case for users of Spack, an open source package management system originally developed to ease the complex builds required by supercomputing environments. To preserve the command line workflow of Spack, we develop an interactive ASCII visualization for its dependency graphs. Through interviews with Spack maintainers, we identify user goals and corresponding visual tasks for dependency graphs. We evaluate the use of our visualization through a command line-centered study, comparing it to the system's two existing approaches. We observe that despite the limitations of the ASCII representation, our visualization is preferred by participants when approached from a command line interface workflow.
The purpose of this NASA Software Management Guidebook is twofold. First, this document defines the core products and activities required of NASA software projects. It defines life-cycle models and activity-related methods but acknowledges that no single life-cycle model is appropriate for all NASA software projects. It also acknowledges that the appropriate method for accomplishing a required activity depends on characteristics of the software project. Second, this guidebook provides specific guidance to software project managers and team leaders in selecting appropriate life cycles and methods to develop a tailored plan for a software engineering project.
New and existing factories that produce and deliver factory-built housing can benefit from construction process simulation modeling to explore the integration of Lean principles in their operations. Construction process simulation modeling provides digital or virtual recreations of the real-world factory environments to visualize, quantify, analyze, and optimize their underlying behavior, including factory productivity, material flow, labor dynamics, bottlenecks, and work scope. One of the key benefits of process simulation modeling is the ability to create and compare "what-if" scenarios, including integrating Lean principles such as reducing waste (for example, transportation, waiting), line balancing, and just-in-time concepts. In general, three process simulation methods are widely used: discrete event simulation (DES), agentbased modeling (ABM), and system dynamics (SD). Myriad process simulation software also is available, but depending on the industry, complexity of the system, and purposes of the simulation, some software might be more appropriate. Similar to how computer-aided design (CAD) software such as AutoCAD and Rhinoceros enable building design of modular or factory-built housing, process simulation modeling software such as jStrobe, ProModel, and AnyLogic can enable factory design of new and existing factories to deliver modular affordable housing at scale, as opposed to traditional site-built construction. Software with DES capabilities can help generate a process model that is a logical representation of resources and activities in a factory. Software with CAD-DES integration can leverage product-process data integration to help spatially visualize a DES model of the factory in the CAD environment. Software with multimethod simulation capabilities, widely used in the manufacturing industry, brings together DES, ABM, and SD in a single platform that allows visualization, quantification, analyses, and optimization at varying data fidelities. Near-real-time data from an existing factory can be directly plugged into multimethod simulation software so that the construction process simulation model is a near-accurate representation of the real-world factory conditions. This report provides insights into the use of simulation as an aid to integrate Lean concepts in factories, including guidelines for selecting the appropriate process simulation modeling method and software. These insights have been developed as part of ongoing process simulation modeling research, development, and demonstration projects at the U.S. Department of Housing and Urban Development, the U.S. Department of Energy, and the National Renewable Energy Laboratory focused on how process simulation models can enable better integration of resilience, energy efficiency, and low-carbon design strategies.
A computer program defines and implements an innovative kind of data structure than can be used for representing information derived from serendipitous discoveries made via collection of scientific data on long exploratory spacecraft missions. Data structures capable of collecting any kind of data can easily be implemented in advance, but the task of designing a fixed and efficient data structure suitable for processing raw data into useful information and taking advantage of serendipitous scientific discovery is becoming increasingly difficult as missions go deeper into space. The present software eases the task by enabling definition of arbitrarily complex data structures that can adapt at run time as raw data are transformed into other types of information. This software runs on a variety of computers, and can be distributed in either source code or binary code form. It must be run in conjunction with any one of a number of Lisp compilers that are available commercially or as shareware. It has no specific memory requirements and depends upon the other software with which it is used. This program is implemented as a library that is called by, and becomes folded into, the other software with which it is used.
Mars rover operations has traditionally controlled behavior using meticulously compiled, so-called “Master” sequences that enforce deterministic timing and ordering of activities. While the approach is effective at managing risk and complexity, it can also be inefficient. Extended operations of the Mars2020 rover envisions a fundamentally different scheduling and execution approach. Atomic activities are constrained by mission operators in time, resource usage, and a structure of dependencies. The rover flight software will create and re-create schedules, responding to available energy, data volume, actual activity durations and execution status, observed temperatures, and other on-board state. Schedules are expected to change substantially in the course of execution. The solution space is prohibitively large and probabilistic in nature. A range of emergent behavior is accessible depending on the interaction between actual on-board state and a given formulation of constraints. For years, the specification and implementation of this capability have been considered and refined, as testing and analysis have mapped the contours of the system. Many concepts that could have been adopted were rejected, and in some cases, emergent properties have been exposed and beaten back with approaches to steer the behavior. This paper discusses some of the design history and underlying reasoning in the systems engineering of the first autonomous activity planner on Mars.
Mission lifecycles have proven to extend well beyond their original design. The benefits to this are countless but introduce challenges in today’s rapidly changing ground infrastructure and software technologies used to enable mission success. What remains constant is the risk posture missions maintain when accepting change and the use of new technologies. Larger missions are ready for change in early lifecycle development but near launch and especially in operations, few continue to evolve beyond what is set in place in phase C. This paper will discuss how the Advance Multi-Mission Operations System (AMMOS) intends to address, three driving missions concerns: Maintaining functionality (hardware/software) for decades, rapidly responding to security vulnerabilities in software, and finally the ability to quickly evolve infrastructure and software changes. These driving concerns are briefly described below: 1. Maintaining functionality (hardware/software) for decades. Hardware updates considerably faster than 10 years ago. Expectations that a system can remain in place for more than 10 years is no longer valid. Expecting to find hardware replacements for a system older than 5 years will increasingly become more and more challenging. How than do missions plan for hardware changes for long lived missions? Principle Objective: Provide abstraction by virtualizing and containerizing software abstract away any hardware dependencies and package up the application lightweight units. 2. Rapidly responding to security vulnerabilities in software. Cost is often the main impediment and largely driven by the revalidation and testing of system that undergo change. In todays, environment security updates are a major diver demanding systems remain up to date. How then do missions accept these changes and avoid large testing efforts? Principle Objective: Help reduce the cost of re-testing by automation of testing, deployment, and compartmentalizing change. 3. Ability to quickly evolve infrastructure and software changes. Responding quickly to change is similar to the second concern in this paper regarding security vulnerabilities. In this case, it address broader concerns of updating software and infrastructure on a more realistic timeline. How do missions stay up to date with the most recent versions of software and allowing for improved functionality? Principle Objective: Use continuous integration techniques at the system level to ensure rapid turnaround. This paper explores each of these concerns in more detail. It focuses the AMMOS’s current plans, challenges and current roadmap.