Engineering Papers⌕ Search

SEARCH · Engineering Papers

Results for “continuous integration”

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 55 records · Page 3

Development of Airport Surface Required Navigation Performance (RNP)

The U.S. and international aviation communities have adopted the Required Navigation Performance (RNP) process for defining aircraft performance when operating the en-route, approach and landing phases of flight. RNP consists primarily of the following key parameters - accuracy, integrity, continuity, and availability. The processes and analytical techniques employed to define en-route, approach and landing RNP have been applied in the development of RNP for the airport surface. To validate the proposed RNP requirements several methods were used. Operational and flight demonstration data were analyzed for conformance with proposed requirements, as were several aircraft flight simulation studies. The pilot failure risk component was analyzed through several hypothetical scenarios. Additional simulator studies are recommended to better quantify crew reactions to failures as well as additional simulator and field testing to validate achieved accuracy performance, This research was performed in support of the NASA Low Visibility Landing and Surface Operations Programs.

Cassell, Rick↗

An Assessment of CFD Effectiveness for Vortex Flow Simulation to Meet Preliminary Design Needs

The low-speed flight and transonic maneuvering characteristics of combat air vehicles designed for efficient supersonic flight are significantly affected by the presence of free vortices. At moderate-to-high angles of attack, the flow invariably separates from the leading edges of the swept slender wings, as well as from the forebodies of the air vehicles, and rolls up to form free vortices. The design of military vehicles is heavily driven by the need to simultaneously improve performance and affordability.1 In order to meet this need, increasing emphasis is being placed on using Modeling & Simulation environments employing the Integrated Product & Process Development (IPPD) concept. The primary focus is on expeditiously providing design teams with high-fidelity data needed to make more informed decisions in the preliminary design stage. Extensive aerodynamic data are needed to support combat air vehicle design. Force and moment data are used to evaluate performance and handling qualities; surface pressures provide inputs for structural design; and flow-field data facilitate system integration. Continuing advances in computational fluid dynamics (CFD) provide an attractive means of generating the desired data in a manner that is responsive to the needs of the preliminary design efforts. The responsiveness is readily characterized as timely delivery of quality data at low cost.

Raj, P.↗

A Roadmap for Using Agile Development in a Traditional Environment

One of the newer classes of software engineering techniques is called 'Agile Development'. In Agile Development software engineers take small implementation steps and, in some cases they program in pairs. In addition, they develop automatic tests prior to implementing their small functional piece. Agile Development focuses on rapid turnaround, incremental planning, customer involvement and continuous integration. Agile Development is not the traditional waterfall method or even a rapid prototyping method (although this methodology is closer to Agile Development). At Jet Propulsion Laboratory (JPL) a few groups have begun Agile Development software implementations. The difficulty with this approach becomes apparent when Agile Development is used in an organization that has specific criteria and requirements handed down for how software development is to be performed. The work at the JPL is performed for the National Aeronautics and Space Agency (NASA). Both organizations have specific requirements, rules and procedure for developing software. This paper will discuss the some of the initial uses of the Agile Development methodology, the spread of this method and the current status of the successful incorporation into the current JPL development policies.

Agile Development↗

A Roadmap for Using Agile Development in a Traditional Environment

One of the newer classes of software engineering techniques is called 'Agile Development'. In Agile Development software engineers take small implementation steps and, in some cases, they program in pairs. In addition, they develop automatic tests prior to implementing their small functional piece. Agile Development focuses on rapid turnaround, incremental planning, customer involvement and continuous integration. Agile Development is not the traditional waterfall method or even a rapid prototyping method (although this methodology is closer to Agile Development). At the Jet Propulsion Laboratory (JPL) a few groups have begun Agile Development software implementations. The difficulty with this approach becomes apparent when Agile Development is used in an organization that has specific criteria and requirements handed down for how software development is to be performed. The work at the JPL is performed for the National Aeronautics and Space Agency (NASA). Both organizations have specific requirements, rules and processes for developing software. This paper will discuss some of the initial uses of the Agile Development methodology, the spread of this method and the current status of the successful incorporation into the current JPL development policies and processes.

software methodology↗

NASA Tech Briefs, April 2011

Topics covered include: Amperometric Solid Electrolyte Oxygen Microsensors with Easy Batch Fabrication; Two-Axis Direct Fluid Shear Stress Sensor for Aerodynamic Applications; Target Assembly to Check Boresight Alignment of Active Sensors; Virtual Sensor Test Instrumentation; Evaluation of the Reflection Coefficient of Microstrip Elements for Reflectarray Antennas; Miniaturized Ka-Band Dual-Channel Radar; Continuous-Integration Laser Energy Lidar Monitor; Miniaturized Airborne Imaging Central Server System; Radiation-Tolerant, SpaceWire-Compatible Switching Fabric; Small Microprocessor for ASIC or FPGA Implementation; Source-Coupled, N-Channel, JFET-Based Digital Logic Gate Structure Using Resistive Level Shifters; High-Voltage-Input Level Translator Using Standard CMOS; Monitoring Digital Closed-Loop Feedback Systems; MASCOT - MATLAB Stability and Control Toolbox; MIRO Continuum Calibration for Asteroid Mode; GOATS Image Projection Component; Coded Modulation in C and MATLAB; Low-Dead-Volume Inlet for Vacuum Chamber; Thermal Control Method for High-Current Wire Bundles by Injecting a Thermally Conductive Filler; Method for Selective Cleaning of Mold Release from Composite Honeycomb Surfaces; Infrared-Bolometer Arrays with Reflective Backshorts; Commercialization of LARC (trade mark) -SI Polyimide Technology; Novel Low-Density Ablators Containing Hyperbranched Poly(azomethine)s; Carbon Nanotubes on Titanium Substrates for Stray Light Suppression; Monolithic, High-Speed Fiber-Optic Switching Array for Lidar; Grid-Tied Photovoltaic Power System; Spectroelectrochemical Instrument Measures TOC; A Miniaturized Video System for Monitoring Drosophila Behavior; Hydrofocusing Bioreactor Produces Anti-Cancer Alkaloids; Creep Measurement Video Extensometer; Radius of Curvature Measurement of Large Optics Using Interferometry and Laser Tracker n-B-pi-p Superlattice Infrared Detector; Safe Onboard Guidance and Control Under Probabilistic Uncertainty; General Tool for Evaluating High-Contrast Coronagraphic Telescope Performance Error Budgets; Hidden Statistics of Schroedinger Equation; Optimal Padding for the Two-Dimensional Fast Fourier Transform; Spatial Query for Planetary Data; Higher Order Mode Coupling in Feed Waveguide of a Planar Slot Array Antenna; Evolutionary Computational Methods for Identifying Emergent Behavior in Autonomous Systems; Sampling Theorem in Terms of the Bandwidth and Sampling Interval; Meteoroid/Orbital Debris Shield Engineering Development Practice and Procedure; Self-Balancing, Optical-Center-Pivot, Fast-Steering Mirror; Wireless Orbiter Hang-Angle Inclinometer System; and Internal Electrostatic Discharge Monitor - IESDM.

Source record↗

Improving operations: Metrics to Results

As a result of the mission failure of the Mars Climate Orbiter (MCO) spacecraft in 1999, the Jet Propulsion Laboratory (JPL) initiated the development of a Mission Operations Assurance (MOA) program to be implemented across all flight projects managed by JPL. One of the initiatives undertaken in 2001 was the collection of data on command file errors occurring in the operational phase of the mission. This paper defines command file errors and how and where they occur in the operations process. It also describes the problem reporting system (PRS) in use for mission operations at JPL. We examine the recent modifications to the PRS that enable the collection of metrics, specifically on command file errors. This paper discusses what the data show us since metrics have been collected for the operational missions conducted by JPL. We examine the evolution of an operational working group initiative to evaluate proximate, contributing, and root causes for the errors. As part of this discussion we see what the metrics have indicated over a decade. At the macro level, we can say that the aggregate command file error rate has been cut to roughly one third of the initial 2001 level by the end of 2011. Additionally, we explore efficient and innovative means to continually integrate the findings and recommendations from the working group back into the flight operations environment.

command file errors↗

Testability, Test Automation and Test Driven Development for the Trick Simulation Toolkit

This paper describes the adoption of a Test Driven Development approach and a Continuous Integration System in the development of the Trick Simulation Toolkit, a generic simulation development environment for creating high fidelity training and engineering simulations at the NASA Johnson Space Center and many other NASA facilities. It describes the approach, and the significant benefits seen, such as fast, thorough and clear test feedback every time code is checked into the code repository. It also describes an approach that encourages development of code that is testable and adaptable.

Penn, John↗

Verification and Validation Studies for the LAVA CFD Solver

The verification and validation of the Launch Ascent and Vehicle Aerodynamics (LAVA) computational fluid dynamics (CFD) solver is presented. A modern strategy for verification and validation is described incorporating verification tests, validation benchmarks, continuous integration and version control methods for automated testing in a collaborative development environment. The purpose of the approach is to integrate the verification and validation process into the development of the solver and improve productivity. This paper uses the Method of Manufactured Solutions (MMS) for the verification of 2D Euler equations, 3D Navier-Stokes equations as well as turbulence models. A method for systematic refinement of unstructured grids is also presented. Verification using inviscid vortex propagation and flow over a flat plate is highlighted. Simulation results using laminar and turbulent flow past a NACA 0012 airfoil and ONERA M6 wing are validated against experimental and numerical data.

Validation↗

Evolution of Software-Only-Simulation at NASA IV and V

Software-Only-Simulations have been an emerging but quickly developing field of study throughout NASA. The NASA Independent Verification Validation (IVV) Independent Test Capability (ITC) team has been rapidly building a collection of simulators for a wide range of NASA missions. ITC specializes in full end-to-end simulations that enable developers, VV personnel, and operators to test-as-you-fly. In four years, the team has delivered a wide variety of spacecraft simulations that have ranged from low complexity science missions such as the Global Precipitation Management (GPM) satellite and the Deep Space Climate Observatory (DSCOVR), to the extremely complex missions such as the James Webb Space Telescope (JWST) and Space Launch System (SLS).This paper describes the evolution of ITCs technologies and processes that have been utilized to design, implement, and deploy end-to-end simulation environments for various NASA missions. A comparison of mission simulators are discussed with focus on technology and lessons learned in complexity, hardware modeling, and continuous integration. The paper also describes the methods for executing the missions unmodified flight software binaries (not cross-compiled) for verification and validation activities.

Embedded↗

Risk of Crew Adverse Health Event Due to Altered Immune Response

Determining the effect of space travel on the human immune system has proven to be extremely challenging. Limited opportunities for in-flight studies, varying mission durations, technical and logistical obstacles, small subject numbers, and a broad range of potential assays have contributed to this problem. Additionally, the inherent complexity of the immune system, with its vast array of cell populations, sub-populations, diverse regulatory molecules, and broad interactions with other physiological systems, makes determining precise variables to measure very difficult. There is also the challenge of determining the clinical significance of any observed immune alterations. Will such a change lead to disease, or is it a transient subclinical observation related to short-term stress? The effect of this problem may be observed by scanning publications associated with immunity and spaceflight, which began to appear during the 1970s. Although individually they are each valid studies, the comprehensive literature to date suffers from widely varying sampling methods and assay techniques, low subject counts, and sometimes a disparate focus on narrow aspects of immunity. The most clinically relevant data are derived from in-flight human studies, which have demonstrated altered cell-mediated immunity and reactivation of latent herpes viruses. Much more data are available from post-flight testing of humans, with clear evidence of altered cytokine production patterns, altered leukocyte distribution, continued latent viral reactivation, and evidence of dramatically altered virus-specific immunity. It is unknown if post-flight assessments relate to the in-flight condition or are a response to landing stress and readaptation. In-flight culture of cells has clearly demonstrated that immune cells are gravity-sensitive and display altered functional characteristics. It is unknown if these data are related to in vivo immune cell function or are an artifact of microgravity culture. Ground analog testing of humans and animals, as well as microgravity-analog cell culture, has demonstrated utility. However, in all cases, it is not known with certainty if these data would reflect similar testing during space travel. Given their ready availability, ground analogs may be extremely useful for assay development and the evaluation of potential countermeasures. In general, the evidence base suffers from widely disparate studies on small numbers of subjects that do not directly correlate well with each other or spaceflight itself. Also lacking are investigations of the effect of gender on adaption to spaceflight. This results in significant knowledge 'gaps' that must be filled by future studies to completely determine any clinical risk related to immunity for human exploration-class space missions. These gaps include a significant lack of in-flight data, particularly during long-duration space missions. The International Space Station represents an excellent science platform with which to address this knowledge gap. Other knowledge gaps include lack of a single validated ground analog for the phenomenon and a lack of flight-compatible laboratory equipment capable of monitoring astronauts (for either clinical or research purposes). However, enough significant data exist, as described in this manuscript, to warrant addressing this phenomenon during the utilization phase of the ISS. A recent Space Shuttle investigation has confirmed the 31 in-flight nature of immune dysregulation, demonstrating that it is not merely a post-flight phenomenon. Several current studies are ongoing onboard the ISS that should thoroughly characterize the phenomenon. NASA recognizes that if spaceflight-associated immune dysregulation persists during exploration flights in conjunction with other dangers, such as high-energy radiation, the result may be a significant clinical risk. This emphasizes the need for a continued integrated comprehensive approach to determining the effect of prolonged spaceflight, separated from transient launch and landing stresses, on human immunity. After such studies, the phenomenon will be understood, and, hopefully, a monitoring strategy will have been developed that could be used to monitor the effectiveness of countermeasure

Crucian, Brian↗

NASA Provides the Capability to Deliver Near Real-Time JPSS Data to Users in Order to Monitor Time-Sensitive Applications Such as Wildfires, Floods, Volcanic Eruptions, Tropical Cyclones and Extreme Weather Events

NASA's Land, Atmosphere Near real-time Capability for EOS (Earth Observing System) (LANCE https://earthdata.nasa.gov/lance) serves near real time (NRT) data to monitor time sensitive applications such as monitoring wildfires, floods, volcanic eruptions, tropical cyclones and extreme weather events. It currently serves data and imagery from the Visible Infrared Imager Radiometer Suite (VIIRS) and Ozone Mapping and Profiler Suite (OMPS) S NPP (Suomi National Polar-orbiting Partnership) instruments and is in the process of integrating continuity data products from VIIRS and OMPS onboard the Joint Polar Satellite System (JPSS), via the JPSS data Hub, to continue to meet the needs of agencies, scientists and members of the general public. NASA's Earth Science Division (ESD) sponsored the EOSDIS development of LANCE in 2009 to provide a central point of access to high quality NRT data products and imagery for applications users. LANCE makes data available to the public within 3 hours of satellite observation and imagery within 4-5 hours of satellite observation. Full resolution browse imagery from LANCE are provided through the Global Imagery Browse Services (GIBS) which also fuels NASA's Worldview tool so that users can interactively browse near real time data. This data supports time critical applications and allows users to view current natural hazards and events and animate the imagery over time.

Near real time↗

Development of Buffet Forcing Functions Using Frequency-Dependent Coherence Factors

The current accepted approach to modeling launch vehicle transonic buffet environments is to acquire time-correlated unsteady pressure measurements at discrete locations on a model-scale wind-tunnel model and use these measurements to develop buffet forcing functions (BFFs).Part of the BFF development process is the application of coherence factors to account for the discrete nature of the pressure measurement used in the development of the BFFs. Presently, the Space Launch System (SLS) program divides the launch vehicle into distinct aerodynamic regions, within which, the coherence lengths are assumed to be constant. The coherence factors are computed by averaging the coherence function between sensors within the region over a specified frequency range. The present work validates and examines the impact of two proposed changes to the development of longitudinal coherence factors used in the development of launch vehicle BFFs. One change is to employ frequency-dependent coherence factors instead of coherence factors based on the mean of the coherence function. The second proposed change replaces the aerodynamic regions with a moving-segment approach that varies the calculated coherence lengths as a function of longitudinal location of the transducers. The impact of these approaches is examined using data from two rigid buffet model wind-tunnel tests: (1)a notional launch vehicle geometry through the comparison of discrete measurement-basedBFFs to loads developed by continuous integration of unsteady pressure sensitive paint data and (2) the SLS Block 1 Cargo vehicle configuration for which BFFs have been previously developed using less-mature methods. The trends from this examination of updated coherence factor approaches ultimately result in more intuitive results than currently-accepted coherence methods.

buffet, unsteady aerodynamics, launch vehicle, win↗

Development of Buffet Forcing Functions Using Frequency-Dependent Coherence Factors

The current accepted approach to modeling launch vehicle transonic buffet environments is to acquire time-correlated unsteady pressure measurements at discrete locations on a model-scale wind-tunnel model and use these measurements to develop buffet forcing functions (BFFs). Part of the BFF development process is the application of coherence factors to account for the discrete nature of the pressure measurement used in the development of the BFFs. Presently, the Space Launch System (SLS) program divides the launch vehicle into distinct aerodynamic regions, within which, the coherence lengths are assumed to be constant. The coherence factors are computed by averaging the coherence function between sensors within the region over a specified frequency range. The present work validates and examines the impact of two proposed changes to the development of longitudinal coherence factors used in the development of launch vehicle BFFs. One change is to employ frequency-dependent coherence factors instead of coherence factors based on the mean of the coherence function. The second proposed change replaces the aerodynamic regions with a moving-segment approach that varies the calculated coherence lengths as a function of longitudinal location of the transducers. The impact of these approaches is examined using data from two rigid buffet model wind-tunnel tests: (1) a notional launch vehicle geometry through the comparison of discrete measurement-based BFFs to loads developed by continuous integration of unsteady pressure sensitive paint data and (2) the SLS Block 1 Cargo vehicle configuration for which BFFs have been previously developed using less-mature methods. The trends from this examination of updated coherence factor approaches ultimately result in more intuitive results than currently-accepted coherence methods.

buffet↗

Ground Software Technologies – Embracing Change: Mission Drivers and Technology Opportunities to Enable Long Lived Missions

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.

Giovannoni, Brian J.↗

Flight Software Dictionary Development for the Mars2020 Rover

The Mars2020 project, developed and operated by the Jet Propulsion Laboratory (JPL), successfully landed the Perseverance rover and its flying companion Ingenuity on the surface of Mars on February 18th 2021. Perseverance combines heritage and cutting-edge flight software and hardware to accomplish crucial mission requirements related to Martian surface sampling. The design, development, and operation of NASA’s large strategic science missions require the ability to communicate spacecraft capabilities to hundreds of engineers across multiple disciplines. The interaction between flight and ground software development, Verification and Validation (V&V), Assembly, Test, and Launch Operations (ATLO), and management each demand quick understanding of unique slices of information for each discipline. This information includes the current capabilities of the flight system as well as future capabilities and their status as they are developed and tested. Despite the fundamental and critical nature of this information, the flight software dictionaries used to track it are a stumbling block for many projects. These dictionaries provide the cornerstone for the interpretation of data sent from the spacecraft, allowing for quick comprehension by engineers on the ground. During both spacecraft development and operations, flight software dictionary management includes significant challenges due to the large number of interfacing systems and the subtle yet distinct needs of each.The engineering of flight software dictionaries for Mars2020 had numerous challenges, most-notably: parallel dictionary development to support simultaneous separate flight software build campaigns for each mission phase (cruise and surface), managing requests for operations-enabling information without perturbing the heritage interface with the rover, and the introduction of new tools by the dictionary stakeholders that forced the dictionary team to innovate and redesign the heritage tool chain. These challenges generated guiding principles for the dictionary development effort: emphasize coding best practices and unit testing in the dictionary code development tool chain, use institutionally provided COTS (commercial-off-the-shelf) tools whenever possible, and maintain the heritage flight-ground interface all while advancing operations-enabling information via a loosely coupled interface.Throughout development and operations, the Mars2020 dictionary toolchain included IBM DOORS Next Generation, GitHub, Microsoft Excel, Docker, Jenkins, and a significant custom-built Python codebase. Significant interfaces included JPL’s command and control software, heritage flight software team tools and processes, and the many cloud-based ground tools developed for the mission.This paper will discuss the requirements for the Mars2020 dictionary development, the development team’s response to those requirements, lessons learned throughout the process, steps taken towards automated deliveries and continuous integration of stakeholder inputs, potential toolchain improvements for Mars2020, and key takeaways that could be applied to future missions.

Pyrzak, Guy↗

Towards Streamlining Auditing for Compliance With Requirements in Open-Source Software at NASA

Context: NASA requires all software to meet several requirements (NPR 7150.2) depending on software criticality. The instantiation of these requirements may vary per project; however, once decided upon, projects must undergo audits to evaluate compliance with these requirements. Aim: We propose that audit effort can be reduced when requirements are realized by leveraging commonly used open-source infrastructure for version control, issue tracking and continuous integration, and the generated records are analyzed using a repository mining software tool to quantify process compliance. Method: We perform a case study in the NASA-funded Copilot project, utilizing Kaiaulu, a repository mining software tool. We define four software compliance metrics based on the Copilot’s requirements, and analyze their impact on source code quality. Results: Our work demonstrates how it is possible to leverage existing open source tools and platforms to facilitate software certification and qualification, and to streamline the auditing process required even when stringent requirements must be enforced. Conclusion: Together, both project and tool can be utilized to visualize project compliance, and metrics can be defined to more easily identify process irregularities to minimize auditing efforts. Project Repository: github.com/Copilot-Language/copilot Tool Repository: github.com/sailuh/kaiaulu

code-quality↗

Safety Arguments for Next Generation, Location Aware Computing

Concerns over accuracy, availability, integrity, and continuity have limited the integration of Global Positioning System (GPS) and Global Navigation Satellite System (GLONASS) for safety-critical applications. More recent augmentation systems, such as the European Geostationary Navigation Overlay Service (EGNOS) and the North American Wide Area Augmentation System (WAAS) have begun to address these concerns. Augmentation architectures build on the existing GPS/GLONASS infrastructures to support location based services in Safety of Life (SoL) applications. Much of the technical development has been directed by air traffic management requirements, in anticipation of the more extensive support to be offered by GPS III and Galileo. WAAS has already been approved to provide vertical guidance for aviation applications. During the next twelve months, the full certification of EGNOS for SoL applications is expected. This paper discusses similarities and differences between the safety assessment techniques used in Europe and North America.

Johnson, C. W.↗