Search NASA⌕ Search

SEARCH · Search NASA

Results for “Software development”

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 613 records · Page 34
All sourcesNASA NTRSDOE OSTI
NASA NTRS2001

Avionics Simulation, Development and Software Engineering

This monthly report summarizes the work performed under contract NAS8-00114 for Marshall Space Flight Center in the following tasks: 1) Purchase Order No. H-32831D, Task Order 001A, GPB Program Software Oversight; 2) Purchase Order No. H-32832D, Task Order 002, ISS EXPRESS Racks Software Support; 3) Purchase Order No. H-32833D, Task Order 003, SSRMS Math Model Integration; 4) Purchase Order No. H-32834D, Task Order 004, GPB Program Hardware Oversight; 5) Purchase Order No. H-32835D, Task Order 005, Electrodynamic Tether Operations and Control Analysis; 6) Purchase Order No. H-32837D, Task Order 007, SRB Command Receiver/Decoder; and 7) Purchase Order No. H-32838D, Task Order 008, AVGS/DART SW and Simulation Support

Francis, Ronald C.↗
NASA NTRS2002

Avionics Simulation, Development and Software Engineering

During this reporting period, all technical responsibilities were accomplished as planned. A close working relationship was maintained with personnel of the MSFC Avionics Department Software Group (ED14), the MSFC EXPRESS Project Office (FD31), and the Huntsville Boeing Company. Accomplishments included: performing special tasks; supporting Software Review Board (SRB), Avionics Test Bed (ATB), and EXPRESS Software Control Panel (ESCP) activities; participating in technical meetings; and coordinating issues between the Boeing Company and the MSFC Project Office.

Source record↗
NASA NTRS2006

Ten Commandments of Formal Methods...Ten Years Later

More than a decade ago, in "Ten Commandments of Formal Methods," we offered practical guidelines for projects that sought to use formal methods. Over the years, the article, which was based on our knowledge of successful industrial projects, has been widely cited and has generated much positive feedback. However, despite this apparent enthusiasm, formal methods use has not greatly increased, and some of the same attitudes about the infeasibility of adopting them persist. Formal methodists believe that introducing greater rigor will improve the software development process and yield software with better structure, greater maintainability, and fewer errors.

Bowen, Jonathan P.↗
NASA NTRS1993

Vacillation Made Easy: Distribution, Re-distribution, and Un-distribution of DOPL-based Processing

Distributed Objects Protocol Layer, or DOPL, Provides a simple and general data communication abstraction that can support the distribution of C++ applications software functionality among an arbitrary collection of processors. The purposed of the abstraction is to minimize the cost of revising processing distribution decisions throughout the software development cycle, including after software has beed delivered to users.

Vacillation↗
NASA NTRS2009

Ares I Avionics Introduction

The Ares I is the next generation human-rated launcher for the United States Constellation program. This system is required to provide single fault tolerance within defined crew safety and mission reliability limits. As part of the effort to achieve those safety goals, Ares I includes an avionics subsystem built as a multistring, voting architecture. The avionics design draws upon experience gained from building fly-by-wire systems for Shuttle, X- 38, and Seawolf. Architectural drivers for the avionics design include using proven technologies with existing suppliers of space rated parts for critical functions (to reduce overall development risk), easing the software development effort by using an off-theshelf, DO-178B certifiable, ARINC-653 operating system in the main flight computers, minimizing mutual data and power connections that might lead to a common-mode hardware failure of the redundant avionics strings, and centralizing overall Ares I command & control within the Upper Stage.

Marchant, Christopher C.↗
NASA NTRS2012

Using Image Pro Plus Software to Develop Particle Mapping on Genesis Solar Wind Collector Surfaces

The continued success of the Genesis mission science team in analyzing solar wind collector array samples is partially based on close collaboration of the JSC curation team with science team members who develop cleaning techniques and those who assess elemental cleanliness at the levels of detection. The goal of this collaboration is to develop a reservoir of solar wind collectors of known cleanliness to be available to investigators. The heart and driving force behind this effort is Genesis mission PI Don Burnett. While JSC contributes characterization, safe clean storage, and benign collector cleaning with ultrapure water (UPW) and UV ozone, Burnett has coordinated more exotic and rigorous cleaning which is contributed by science team members. He also coordinates cleanliness assessment requiring expertise and instruments not available in curation, such as XPS, TRXRF [1,2] and synchrotron TRXRF. JSC participates by optically documenting the particle distributions as cleaning steps progress. Thus, optical document supplements SEM imaging and analysis, and elemental assessment by TRXRF.

Rodriquez, Melissa C.↗
NASA NTRS2014

Brainwave Monitoring Software Improves Distracted Minds

Neurofeedback technology developed at Langley Research Center to monitor pilot awareness inspired Peter Freer to develop software for improving student performance. His company, Fletcher, North Carolina-based Unique Logic and Technology Inc., has gone on to develop technology for improving workplace and sports performance, monitoring drowsiness, and encouraging relaxation.

Source record↗
NASA NTRS2015

FEAMAC-CARES Software Coupling Development Effort for CMC Stochastic-Strength-Based Damage Simulation

Reported here is a coupling of two NASA developed codes: CARES (Ceramics Analysis and Reliability Evaluation of Structures) with the MACGMC composite material analysis code. The resulting code is called FEAMACCARES and is constructed as an Abaqus finite element analysis UMAT (user defined material). Here we describe the FEAMACCARES code and an example problem (taken from the open literature) of a laminated CMC in off-axis loading is shown. FEAMACCARES performs stochastic-strength-based damage simulation response of a CMC under multiaxial loading using elastic stiffness reduction of the failed elements.

Reliability↗
NASA NTRS2018

Analysis and Review of NASA Earth Science Metadata: How Automation Plays a Role

The Analysis and Review of the Common Metadata Repository (CMR ARC) Team reviews all EOSDIS metadata. The team’s objective is to achieve consistency, correctness, and completeness for all metadata records in the CMR, as well as improve the discoverability of NASA's Earth Science data within the CMR framework. This work is currently being completed at Marshall Space Flight Center. CMR makes a single discovery point possible for NASA's Earth Science data users. The CMR team, in collaboration with three other core metadata teams, contributes to the stewardship of NASA's Earth Science data through a process of continual curation and the ongoing development of the Unified Metadata Model (UMM). A key tool now used in the curation process, referred to as the NASA CMR Dashboard, is an online curation dashboard developed in collaboration with software development company, Element 84. This tool facilitates the review of Earth Science metadata records and subsequent stakeholder collaboration on the resolution of identified issues. A key capability of the new tool is a suite of automated compliance checks written in Python 3.6 that verify the integrity of various metadata elements across multiple standards.

Staton, Patrick↗
NASA NTRS1990

Knowledge-based systems and NASA's software support environment

A proposed role for knowledge-based systems within NASA's Software Support Environment (SSE) is described. The SSE is chartered to support all software development for the Space Station Freedom Program (SSFP). This includes support for development of knowledge-based systems and the integration of these systems with conventional software systems. In addition to the support of development of knowledge-based systems, various software development functions provided by the SSE will utilize knowledge-based systems technology.

Dugan, Tim↗
NASA NTRS1985

Measuring the software process and product: Lessons learned in the SEL

The software development process and product can and should be measured. The software measurement process at the Software Engineering Laboratory (SEL) has taught a major lesson: develop a goal-driven paradigm (also characterized as a goal/question/metric paradigm) for data collection. Project analysis under this paradigm leads to a design for evaluating and improving the methodology of software development and maintenance.

Basili, V. R.↗
NASA NTRS2008

Constellation Training Facility Support

The National Aeronautics and Space Administration is developing the next set of vehicles that will take men back to the moon under the Constellation Program. The Constellation Training Facility (CxTF) is a project in development that will be used to train astronauts, instructors, and flight controllers on the operation of Constellation Program vehicles. It will also be used for procedure verification and validation of flight software and console tools. The CxTF will have simulations for the Crew Exploration Vehicle (CEV), Crew Module (CM), CEV Service Module (SM), Launch Abort System (LAS), Spacecraft Adapter (SA), Crew Launch Vehicle (CLV), Pressurized Cargo Variant CM, Pressurized Cargo Variant SM, Cargo Launch Vehicle, Earth Departure Stage (EDS), and the Lunar Surface Access Module (LSAM). The Facility will consist of part-task and full-task trainers, each with a specific set of mission training capabilities. Part task trainers will be used for focused training on a single vehicle system or set of related systems. Full task trainers will be used for training on complete vehicles and all of its subsystems. Support was provided in both software development and project planning areas of the CxTF project. Simulation software was developed for the hydraulic system of the Thrust Vector Control (TVC) of the ARES I launch vehicle. The TVC system is in charge of the actuation of the nozzle gimbals for navigation control of the upper stage of the ARES I rocket. Also, software was developed using C standards to send and receive data to and from hand controllers to be used in CxTF cockpit simulations. The hand controllers provided movement in all six rotational and translational axes. Under Project Planning & Control, support was provided to the development and maintenance of integrated schedules for both the Constellation Training Facility and Missions Operations Facilities Division. These schedules maintain communication between projects in different levels. The CxTF support provided is one that requires continuous maintenance since the project is still on initial development phases.

Flores, Jose M.↗
NASA NTRS2014

Towards Test Driven Development for Computational Science with pFUnit

Developers working in Computational Science & Engineering (CSE)/High Performance Computing (HPC) must contend with constant change due to advances in computing technology and science. Test Driven Development (TDD) is a methodology that mitigates software development risks due to change at the cost of adding comprehensive and continuous testing to the development process. Testing frameworks tailored for CSE/HPC, like pFUnit, can lower the barriers to such testing, yet CSE software faces unique constraints foreign to the broader software engineering community. Effective testing of numerical software requires a comprehensive suite of oracles, i.e., use cases with known answers, as well as robust estimates for the unavoidable numerical errors associated with implementation with finite-precision arithmetic. At first glance these concerns often seem exceedingly challenging or even insurmountable for real-world scientific applications. However, we argue that this common perception is incorrect and driven by (1) a conflation between model validation and software verification and (2) the general tendency in the scientific community to develop relatively coarse-grained, large procedures that compound numerous algorithmic steps.We believe TDD can be applied routinely to numerical software if developers pursue fine-grained implementations that permit testing, neatly side-stepping concerns about needing nontrivial oracles as well as the accumulation of errors. We present an example of a successful, complex legacy CSE/HPC code whose development process shares some aspects with TDD, which we contrast with current and potential capabilities. A mix of our proposed methodology and framework support should enable everyday use of TDD by CSE-expert developers.

pFUnit↗
NASA NTRS2006

Deductive Glue Code Synthesis for Embedded Software Systems Based on Code Patterns

Automated code synthesis is a constructive process that can be used to generate programs from specifications. It can, thus, greatly reduce the software development cost and time. The use of formal code synthesis approach for software generation further increases the dependability of the system. Though code synthesis has many potential benefits, the synthesis techniques are still limited. Meanwhile, components are widely used in embedded system development. Applying code synthesis to component based software development (CBSD) process can greatly enhance the capability of code synthesis while reducing the component composition efforts. In this paper, we discuss the issues and techniques for applying deductive code synthesis techniques to CBSD. For deductive synthesis in CBSD, a rule base is the key for inferring appropriate component composition. We use the code patterns to guide the development of rules. Code patterns have been proposed to capture the typical usages of the components. Several general composition operations have been identified to facilitate systematic composition. We present the technique for rule development and automated generation of new patterns from existing code patterns. A case study of using this method in building a real-time control system is also presented.

automated code synthesis↗
NASA NTRS2009

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↗