Defining a Strategy for the Next Release of AIRS Software: How Do We Get to V7 from Here?
No abstract available
Friedman, Steven↗
SEARCH · Search NASA
Results for “Software Release”
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.
E-Control: First Public Release of Remote Control Software for VLBI Telescopes
Automating and remotely controlling observations are important for future operations in a Global Geodetic Observing System (GGOS). At the Geodetic Observatory Wettzell, in cooperation with the Max-Planck-Institute for Radio Astronomy in Bonn, a software extension to the existing NASA Field System has been developed for remote control. It uses the principle of a remotely accessible, autonomous process cell as a server extension for the Field System. The communication is realized for low transfer rates using Remote Procedure Calls (RPC). It uses generative programming with the interface software generator idl2rpc.pl developed at Wettzell. The user interacts with this system over a modern graphical user interface created with wxWidgets. For security reasons the communication is automatically tunneled through a Secure Shell (SSH) session to the telescope. There are already successful test observations with the telescopes at O Higgins, Concepcion, and Wettzell. At Wettzell the software is already used routinely for weekend observations. Therefore the first public release of the software is now available, which will also be useful for other telescopes.
Neidhardt, Alexander↗
Software Management Environment (SME) release 9.4 user reference material
This document contains user reference material for the Software Management Environment (SME) prototype, developed for the Systems Development Branch (Code 552) of the Flight Dynamics Division (FDD) of Goddard Space Flight Center (GSFC). The SME provides an integrated set of management tools that can be used by software development managers in their day-to-day management and planning activities. This document provides an overview of the SME, a description of all functions, and detailed instructions concerning the software's installation and use.
Hendrick, R.↗
XRF-XFS-XAS-Auto v1.0 - Beta release
This software allows to analyze XRF maps, XFS spectra and XAS spectra collected at the Advanced Light Source's Beamline 10.3.2. Features include: 1) XRF maps: - process XRF maps, all elemental maps are saved as bmp automatically and labeled with the incident energy used, the scale bar is also labeled and can be controlled. - XRF elemental correlation plots, save the correlation plots automatically - Extract single or multiple transects in XRF maps on one or several regions of interest, each transect profile is numbered and saved in a corresponding folder, along with the corresponding maps showing transect location. 2) XFS spectra - save in log10 scale the XFS spectra, either a single or multiple files all at once. The files are saved as .bmp. - XFS spectra are labeled according to tabulated fluorescence emission lines. 3) XAS spectra - allows to plot individual scalers in the raw data. - allows calibration of the spectra using an Io internal glitch present in all spectra and performing 1st derivative. - Least-square linear combination fitting of XANES or extended XANES spectra using a database of standards using 1, 2 or 3 components maximum. It also provides the 5 top combinations and provide the user for the possibility of saving the 2nd, 3rd, 4th and 5th best combinations in addition to the best one. The processed spectra (pre-edge background substracted, post-edge normalized), the fits and residuals are automatically saved. A table of the component, with fit% and SSN is provided and saved automatically as well.
Fakra, Sirine↗
CEED-MS34: Improve performance and capabilities of CEED-enabled ECP applications on Summit/Sierra. Exascale Computing Project Milestone Report
The main goal of this milestone was to help CEED-enabled ECP applications, including ExaSMR, MARBL, ExaWind and ExaAM, to improve their performance and capabilities on GPU systems like Summit and Lassen/Sierra. In addition, the CEED team also worked to: add and improve support for additional hardware and programming models in the CEED software components; release the next version of the CEED software stack, CEED-3.0; and demonstrate performance of libParanumal kernels in libCEED, Nek and MFEM. These additional tasks contributed directly to the main CEED-MS34 goal and will also play an important role in CEED’s future milestones.
97 MATHEMATICS AND COMPUTING↗
NASA Shuttle Training Aircraft flight simulation overview
The Shuttle Training Aircraft (STA) is a variable stability, variable control law flying simulator used by NASA/JSC to train astronauts in the final landing phase of a Space Shuttle Orbiter. A general outline is given for the STA flight simulation system. An overview is given of the software generation and verification process through the Advanced Validation System (AVAS). The flight test techniques for software verification will be reviewed and the process for releasing the software for flight training will be covered. The astronaut STA training syllabus is examined. Parameter matching with the Orbiter in the final approach phase of de-orbit and landing is briefly examined. Simulation performance will be assessed against flight data, performance measurement, and cue synchronization.
Justiz, Charles R.↗
Telescience Resource Kit (TReK)
Telescience Resource Kit (TReK) is one of the Huntsville Operations Support Center (HOSC) remote operations solutions. It can be used to monitor and control International Space Station (ISS) payloads from anywhere in the world. It is comprised of a suite of software applications and libraries that provide generic data system capabilities and access to HOSC services. The TReK Software has been operational since 2000. A new cross-platform version of TReK is under development. The new software is being released in phases during the 2014-2016 timeframe. The TReK Release 3.x series of software is the original TReK software that has been operational since 2000. This software runs on Windows. It contains capabilities to support traditional telemetry and commanding using CCSDS (Consultative Committee for Space Data Systems) packets. The TReK Release 4.x series of software is the new cross platform software. It runs on Windows and Linux. The new TReK software will support communication using standard IP protocols and traditional telemetry and commanding. All the software listed above is compatible and can be installed and run together on Windows. The new TReK software contains a suite of software that can be used by payload developers on the ground and onboard (TReK Toolkit). TReK Toolkit is a suite of lightweight libraries and utility applications for use onboard and on the ground. TReK Desktop is the full suite of TReK software -most useful on the ground. When TReK Desktop is released, the TReK installation program will provide the option to choose just the TReK Toolkit portion of the software or the full TReK Desktop suite. The ISS program is providing the TReK Toolkit software as a generic flight software capability offered as a standard service to payloads. TReK Software Verification was conducted during the April/May 2015 timeframe. Payload teams using the TReK software onboard can reference the TReK software verification. TReK will be demonstrated on-orbit running on an ISS provided T61p laptop. Target Timeframe: September 2015 -2016. The on-orbit demonstration will collect benchmark metrics, and will be used in the future to provide live demonstrations during ISS Payload Conferences. Benchmark metrics and demonstrations will address the protocols described in SSP 52050-0047 Ku Forward section 3.3.7. (Associated term: CCSDS File Delivery Protocol (CFDP)).
Lippincott, Jeff↗
Factors That Affect Software Testability
Software faults that infrequently affect software's output are dangerous. When a software fault causes frequent software failures, testing is likely to reveal the fault before the software is releases; when the fault remains undetected during testing, it can cause disaster after the software is installed. A technique for predicting whether a particular piece of software is likely to reveal faults within itself during testing is found in [Voas91b]. A piece of software that is likely to reveal faults within itself during testing is said to have high testability. A piece of software that is not likely to reveal faults within itself during testing is said to have low testability. It is preferable to design software with higher testabilities from the outset, i.e., create software with as high of a degree of testability as possible to avoid the problems of having undetected faults that are associated with low testability. Information loss is a phenomenon that occurs during program execution that increases the likelihood that a fault will remain undetected. In this paper, I identify two brad classes of information loss, define them, and suggest ways of predicting the potential for information loss to occur. We do this in order to decrease the likelihood that faults will remain undetected during testing.
Voas, Jeffrey M.↗
IPAD project overview
To respond to national needs for improved productivity in engineering design and manufacturing, a NASA supported joint industry/government project is underway denoted Integrated Programs for Aerospace-Vehicle Design (IPAD). The objective is to improve engineering productivity through better use of computer technology. It focuses on development of technology and associated software for integrated company-wide management of engineering information. The project has been underway since 1976 under the guidance of an Industry Technical Advisory Board (ITAB) composed of representatives of major engineering and computer companies and in close collaboration with the Air Force Integrated Computer-Aided Manufacturing (ICAM) program. Results to date on the IPAD project include an in-depth documentation of a representative design process for a large engineering project, the definition and design of computer-aided design software needed to support that process, and the release of prototype software to integrate selected design functions. Ongoing work concentrates on development of prototype software to manage engineering information, and initial software is nearing release.
Fulton, R. E.↗
External Release of Organic Scintillator DRiFT Software - Technology Evaluation and Demonstration Project Accomplishments [Slides]
Overview and Objectives: DRiFT post processes radiation transport output from MCNP, and generates realistic nuclear instrumentation response; Organic scintillator response has been developed, tested, and validated with measurements, these instruments are widely used in nuclear safeguards. At the beginning of this project, DRiFT was only available to LANL employees with access to yellow High Performance Computing clusters. Additionally, there are many complicated external software dependencies. Our TED project request proposed using funds to: Comment and clean up code, friendly testing, generating test suites and examples; Expansion of scintillator types natively supported by DRiFT; External release of DRiFT accompanied by documentation. We accomplished all objectives (and many others), they are highlighted in these slides.
73 NUCLEAR PHYSICS AND RADIATION PHYSICS↗
Extreme Programming: Maestro Style
"Extreme Programming: Maestro Style" is the name of a computer programming methodology that has evolved as a custom version of a methodology, called extreme programming that has been practiced in the software industry since the late 1990s. The name of this version reflects its origin in the work of the Maestro team at NASA's Jet Propulsion Laboratory that develops software for Mars exploration missions. Extreme programming is oriented toward agile development of software resting on values of simplicity, communication, testing, and aggressiveness. Extreme programming involves use of methods of rapidly building and disseminating institutional knowledge among members of a computer-programming team to give all the members a shared view that matches the view of the customers for whom the software system is to be developed. Extreme programming includes frequent planning by programmers in collaboration with customers, continually examining and rewriting code in striving for the simplest workable software designs, a system metaphor (basically, an abstraction of the system that provides easy-to-remember software-naming conventions and insight into the architecture of the system), programmers working in pairs, adherence to a set of coding standards, collaboration of customers and programmers, frequent verbal communication, frequent releases of software in small increments of development, repeated testing of the developmental software by both programmers and customers, and continuous interaction between the team and the customers. The environment in which the Maestro team works requires the team to quickly adapt to changing needs of its customers. In addition, the team cannot afford to accept unnecessary development risk. Extreme programming enables the Maestro team to remain agile and provide high-quality software and service to its customers. However, several factors in the Maestro environment have made it necessary to modify some of the conventional extreme-programming practices. The single most influential of these factors is that continuous interaction between customers and programmers is not feasible.
Norris, Jeffrey↗
In-Flight Evaluation of the Traffic Aware Planner on the NASA HU-25A Guardian Aircraft
NASA’s Traffic Aware Planner (TAP) software is a research-prototype decision support tool that provides pilots with time- and fuel-saving route recommendations that optimize their current trajectory. The software runs on a first-of-a-kind system architecture onboard three aircraft in revenue service conducting operational evaluations with a major domestic airline. Therefore, significant NASA-internal testing is required prior to releasing the software to the partner airline. This paper describes a flight test plan that exercises the functionality of the TAP software in a representative operational environment, describes the system architecture developed and implemented for the NASA Langley HU-25A Guardian aircraft to support the test objectives, presents outcomes of the flight test campaign, and discusses use cases that demonstrate the value of flight testing for this activity.Research into flight path optimization of transport aircraft conducted by the National Aeronautics and SpaceAdministration (NASA) has produced an operational concept known as Traffic Aware Strategic Aircrew Requests(TASAR) [1, 2]. This near-term concept [3] provides the aircrew with a flight deck decision support tool known asthe Traffic Aware Planner (TAP). The TAP software leverages a growing number of information sources on the flightdeck to make time- and fuel-saving route optimization recommendations to the aircrew while en route. The aircrewcan then use the suggestions provided by the tool to make route change requests with a greater likelihood of acceptanceby air traffic control (ATC). Since TASAR is a concept intended for the current operational environment, it isintentionally designed to have no safety-critical impact or require any changes to current Federal AviationAdministration (FAA) rules and procedures [4, 5].The research prototype TAP system [6–8], explained further in Section III.C, continually incorporates up-to-dateaircraft state data from onboard avionics, as well as the latest position of surrounding traffic, the most recent windforecast, and the most recent convective weather forecast, in order to calculate candidate trajectory modifications thatimprove upon the current active route. These trajectories account for user-selectable objective functions [3] of reducedfuel burn, reduced flight time, or an airline-derived combination of factors known as trip cost. Previous analyses andsimulations have estimated substantial savings for airlines employing this technique within the U.S. National AirspaceSystem (NAS) [9–11]. Operational evaluations with Alaska Airlines seek to validate these projected benefits usingmeasured data while simultaneously providing benefits to the airline [12, 13].The TAP software has undergone a number of human-in-the-loop simulations [14] and flight test activities[15–17] in order to validate the operational concept, evaluate human factors considerations (e.g., workload, usability,distraction, etc.), and to assess the ability of the software to function in a representative operational environment (e.g.,connected to live avionics data, using in-flight internet connectivity, etc.). However, these simulations and flight testcampaigns did not account for the hardware architecture implemented on the three aircraft for Alaska Airlines’operational evaluations of the TAP software. Therefore, a need was identified to thoroughly test the functionality ofthe software in a similar hardware architecture to that of the partner airline’s aircraft. Information regarding testapparatus and environments used to evaluate TAP prior to testing on the HU-25A can be found in reference [18].A campaign of flight trials on a NASA aircraft, the HU-25A Guardian, was conducted to ensure that the researchprototype TAP system functions well in a configuration similar to the Alaska Airlines aircraft prior to deployment.This airborne, networked environment enables an assessment of the operational factors unique to the flight environment. Additionally, this activity evaluated the effectiveness and benefit of new TAP functionality andoperation in a relevant flight environment while allowing the rapid prototyping of new concepts and features.This paper is organized as follows: Section II discusses the details of the flight test plan, flight profiles, and theduties of personnel involved with conducting flight operations. Section III describes the test platform, avionicsequipage, and system architecture. Section IV presents a discussion of results, and Section V contains concludingremarks.
Underwood, Matthew C.↗
Updates on HRF Payloads Operations in Columbus ATCS
The NASA developed Human Research Facility 1 (HRF1) and Human Research Facility (HRF2) experiment racks have been operating in the European Space Agency (ESA) Columbus module of the International Space Station (ISS) since Summer 2008. The two racks are of the same design. Since the start of operations, unexpected pressure spikes were observed in the Columbus module's thermal-hydraulic system during the racks activation sequence. The root cause of these spikes was identified in the activation command sequence in the Rack Interface Controller (RIC), which controls the flow of thermal-hydraulic system fluid through the rack. A new Common RIC Software (CRS) release fixed the bug and was uploaded on both racks in late 2009. This paper gives a short introduction to the topic, describes the Columbus module countermeasures to mitigate the spikes, describes the ground validation test of the new software, and describes the flight checks performed before and after the final upload. Finally, the new on-orbit test designed to further simplify the racks hydraulic management is presented.
DePalo, Savino↗
World Wind Tools Reveal Environmental Change
Originally developed under NASA's Learning Technologies program as a tool to engage and inspire students, World Wind software was released under the NASA Open Source Agreement license. Honolulu, Hawaii based Intelesense Technologies is one of the companies currently making use of the technology for environmental, public health, and other monitoring applications for nonprofit organizations and Government agencies. The company saved about $1 million in development costs by using the NASA software.
Source record↗
Improvements to Contributions from Neutron Inelastic Scattering for Next-Event Estimators in MCNP ® Software
An improvement to the handling of contributions from neutron inelastic scattering to next-event estimators has been implemented in the MCNP6 ® software for release with version 6.3.1. The kinematic equations that govern the outgoing energy of inelastic neutron scattering contributions to next-event estimators have two roots. Historically, the implementation in the MCNP coding has only used the upper root to the quadratic equation. This includes all versions predating version 6.3.1 including all versions of MCNP5 and MCNPX software. However, a review of the neutron next-event estimator physics has shown that this does not reproduce the track-length estimator results at low energies. Several examples are presented that test single neutron inelastic scattering reaction types, Level Scattering (Law 3), Tabulated Energy Angle (Law 61), and Kalbach-Mann distribution (Law 44). The test problems compare the track-length estimator (f4 tally) in the MCNP software, with the existing implementation of the neutron next-event estimator (f5 tally), and the modified changes to the neutron next-event estimator implementation. As the MCNP implementation ignores the lower root, the unmodified neutron next-event estimators will generally underestimate the lower energy contribution. However, a second issue with the Kalbach-Mann distribution (Law 44) implementation allows contributions to backward scattering in the center-of-mass frame that is not kinematically possible, thus overestimating backward scattering contributions. A third issue with the way the MCNP implementation handles floating point comparison for scattering directly ahead or directly backward in the center-of-mass frame generally leads to underestimation (except for backwards scattering for Law 44).
73 NUCLEAR PHYSICS AND RADIATION PHYSICS↗
Mapping and Quantification of Vascular Branching in Plants, Animals and Humans by VESGEN Software
Humans face daunting challenges in the successful exploration and colonization of space, including adverse alterations in gravity and radiation. The Earth-determined biology of plants, animals and humans is significantly modified in such extraterrestrial environments. One physiological requirement shared by larger plants and animals with humans is a complex, highly branching vascular system that is dynamically responsive to cellular metabolism, immunological protection and specialized cellular/tissue function. VESsel GENeration (VESGEN) Analysis has been developed as a mature beta version, pre-release research software for mapping and quantification of the fractal-based complexity of vascular branching. Alterations in vascular branching pattern can provide informative read-outs of altered vascular regulation. Originally developed for biomedical applications in angiogenesis, VESGEN 2D has provided novel insights into the cytokine, transgenic and therapeutic regulation of angiogenesis, lymphangiogenesis and other microvascular remodeling phenomena. Vascular trees, networks and tree-network composites are mapped and quantified. Applications include disease progression from clinical ophthalmic images of the human retina; experimental regulation of vascular remodeling in the mouse retina; avian and mouse coronary vasculature, and other experimental models in vivo. We envision that altered branching in the leaves of plants studied on ISS such as Arabidopsis thaliana cans also be analyzed.
Parsons-Wingerter, P. A.↗
Mapping and Quantification of Vascular Branching in Plants, Animals and Humans by VESGEN Software
Humans face daunting challenges in the successful exploration and colonization of space, including adverse alterations in gravity and radiation. The Earth-determined biology of humans, animals and plants is significantly modified in such extraterrestrial environments. One physiological requirement shared by humans with larger plants and animals is a complex, highly branching vascular system that is dynamically responsive to cellular metabolism, immunological protection and specialized cellular/tissue function. The VESsel GENeration (VESGEN) Analysis has been developed as a mature beta version, pre-release research software for mapping and quantification of the fractal-based complexity of vascular branching. Alterations in vascular branching pattern can provide informative read-outs of altered vascular regulation. Originally developed for biomedical applications in angiogenesis, VESGEN 2D has provided novel insights into the cytokine, transgenic and therapeutic regulation of angiogenesis, lymphangiogenesis and other microvascular remodeling phenomena. Vascular trees, networks and tree-network composites are mapped and quantified. Applications include disease progression from clinical ophthalmic images of the human retina; experimental regulation of vascular remodeling in the mouse retina; avian and mouse coronary vasculature, and other experimental models in vivo. We envision that altered branching in the leaves of plants studied on ISS such as Arabidopsis thaliana cans also be analyzed.
Parsons-Wingerter, Patricia A.↗
Hybridized Agile Software Development of Flight Control Team Tools for International Space Station's Payload Operations Integration Center
Ground systems operations at the National Aeronautics and Space Administration's (NASA) Payload Operations and Integration Function (POIF) is increasing, via the High Operations Tempo (HOT) initiative, its ability to support more science activities with a fourth crew member on the International Space Station (ISS). The Flight Control Team's need to support this increased crew presence mandated the need for a series of software tools to better handle the increasing pace of payload science operations. The overall need was clear from the outset, but the full scope and user experience for each tool, were not as well understood, so establishing a fixed set of initial requirements was not feasible. An Agile Software Development (ASD) paradigm takes advantage of uncertainty, and plans for it, so it was deemed the most appropriate approach to create room for exploring novel concepts, and to mount a rapid and flexible response to inevitiably changing requirements. It facilitated the need for unprecedented collaboration between the Product Team (i.e. users from the Flight Control Team) and the Development Team (i.e. POIC systems engineers, developers, testers). This is a process shift in the development, test, and release of software from one that is prescriptive to one that is adaptive, which is necessary for these tools to have longevity. The application of ASD to the product development lifecycle permitted the timely incorporation of customer feedback, and, allowed for continuous quality improvements. This resulted in a suite of tools that are efficient, user-friendly, and enable POIF ground systems to support the increasing pace of payload science operations. ASD is not as much a set of prescriptive processes as it is a shift in mindset; one that moves from planning against change, to planning for change, thereby iteratively growing software towards user-defined value.
Albers, Cerese M.↗